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Information system design for administrative systems has 
always taken enormous time and manpower. Most often, the rea- 
son for this is a c onmuni cati on gap between the user and the 
systems analyst created by an inadequate description of the 
user's problem. This calls for many iterations of the various 
phases of the system development cycle. The problem cf reducing 
the time and efforts required for the information system develop- 
ment has been taken up in this thesis. The main idea is to in- 
troduce the computer as a tool in the system development cycle. 

A lot of work is being done in this direction. Some of the 
systemglike Hoskyn's System, ISDOS and PROTO SYSTEM I - BOTTOM 
PART etc., have tried to use the computer as an aid for the auto- 
mation of the design phase. Systems are also being developed to 
automate the problem acquisition phase. The business definition 
language attempts to describe the functions of the organisation. 



Query-by-exanple, SEQUEL, RIL and HI-IQ attempt to use tuple 
based data selection for the problem description. 

In this thesis we approach the problem by considering 
system description and system analysis phases as of basic 

importance because of the dependence of other phases on these 

© 

two phases. To make the approach practicable, the problem 
acquisition phase is reduced from a function description of 
the user's problem to the description of user's data process- 
ing requirements only. 

A language is needed for data processing systems which 
will be able to describe the data transformations needed by 
the user vdthout getting into the procedural details of how 
such data would be managed. This language should also be 
suitable for precisely describing the interaction of the target 
information system with its environment . The basic specifica- 
tion of an information system can be given by describing its 
inputs, outputs or reports, associated timings and the data 
transf omati ons . 

The proposed methodology considers reports as the starting 
point of the information system description. A language is deve- 
loped for describing the reports completely by giving the logical 
structure of the reports. Special features are incorporated in 
this language to describe aspects related to the reporting medium 
or the device. The nature of input documents is similar to that 
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of reports. Thus, this language also has features to describe 
input document s . 

The second part of this language incorporates features 
needed for describing data association or the internal pro- 
perties of the required information system. This language 
is based on a block structure approach to provide data oriented 
control structures. Data selection by identifying subsets of 
data by their properties, creation of such subsets of data and 
data generation are developed as special features of this 
language. 

Time has been used as a special concept. The control 
structure is used to identify different kinds of needs of up- 
dating so that the update aspects can be further utilised. The 
three different features of SDL, those of report description 
input document description and data transformation description, 
together can be used to completely describe the required 
information system. 

In the proposed methodology, tho SDL description is used 
to derive the data needs for the reports. An algorithm for doing 
this has been implemented. Further data needs are identified fear 
carrying out various data transformations. The data availability 
from the input documents and from the data transformations is 
also derived. The needs are matched against the availability. 



The method for doing this is described. This brings out the 
nissing information and superfluous information. 

In real life, systems need more detailed analysis. Ideas 
have been developed to analyse system descriptions in SDL, in 
greater detail to point out the shortcomings of the description. 
The structure of the language can also be used to collect in- 
formation related to system design interactively from the user. 
How queries nay be generated algorithmically to interact with 
the user for correcting the system description at a detailed 
level has been described. 

In conclusion it can be said that the process of system 
analysis and description can be aided by the computer by using 
SDL which is aimed at describing data associations. 



CHAPTER 1 


INTRODUCTION 

With the increased availability of computers, data has become 

a more available resource to control the activity of business and 
* 

this has led to a tremendous increase in the development of manage- 
ment information systems of various kinds* Today, almost eighty 
percent of the total available computing power is being used for 
business systems and therefore they are of primary interest to the 
computer industry. 

In near future potential users of data processing and new 
areas of industrial and administrative applications will generate 
an increasing demand for programming man— power. To keep such man- 
power requirements to a realisable level research is needed towards 
the automation of system design. Development of sophisticated soft- 
ware tools and advacement of design methodologies is envisaged to 
reduce the system design efforts and time. To cut down the system 
development time, enhancement in quality, speed, and ease of develop- 
ment is also necessary. The objective of this thesis is to develop 
such computer aids for system design of man agement information 
systems. 

1-1 . THE PROBLEM OP INFORMATION SYSTEM DESIGN 

Systems like inventory accounting, personnel payroll, manu- 
facturing control, accounting, air line reservations, banking etc., 


1 
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normally constitute the class of data processing systems. Ihe pro- 
cess of system design at the current state-of-art level can be des- 
cribed in terms of five phases: problem acquisition, system analysis, 
system design, system generation or implementation and testing. At 
different stages of development, iterations over some of these phases 
become necessary due to ambiguity in specifications or due to erro- 
neous analysis. A schematic diagram of this process, given in 
ligure 1-1 summarises the various feedback loops in this process. 

In the problem acquisition phase the information needs of the 
organisation are identified. With the help of a dialogue between 
the user and the systems analyst, the information flow in the orga- 
nisation is communicated to the systems analyst. A narrative docu- 
mentation is created and the feasibility of a realistic design is 
studied. 

In the systems analysis phase, with a basic design in mind, the 
data processing needs of the user’s system are identified in greater 
detail and documented by using various kinds of forms specific to an 
installation. What can not be specified in forms is put down as a 
narrative. Quite often, reiteration of the problem acquisition phase 
is needed. These system specifications are considered as the begin- 
ning point for the design phase of this iteration. 

System design phase is the evaluation of alternative designs, 
generation of program specifications, file specifications, and system 
control requirements in terms of flow charts etc. Most often the 




Figure 1-1. System Development Cycle 








system designer is expected to be the same person as the systems 
analyst due to embedded ambiguity in the specification of the 
system. 
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Phases of implementation and testing require programming and 
operational work, (These are normally the phases that require small 
iterations over the whole process of design due to various types of 
errors that are unavoidable during problem acquisition and analysis. 
An approximate break up of the technical work requirements [PRY-76 ] 


is as follows : 

1 . Problem statement 8% 

2. Functional specification 22 % 

3* File structure and module design 15% 

4. Program design, coding and debugging 25% 

5. Integration and installation 30% 


Attempts ih current research are towards reducing the system 
development time and effort by introducing the computer in the in- 
formation system design loop, in the form of an aid, and further, 
if possible, in the form of a basic designing unit. If the infor- 
mation needs of the organisation are specified in such a manner that 
the specifications have less errors and are more complete in a logi- 
cal sense, then the number of iterations over the system develop- 
ment cycle will be reduced thereby reducing the time and effort 
required. 
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If the information needs can he recorded in a consistent and 
formal manner, then seme of the work of analysis, design and gene- 
ration can be automated* This would reduce the involvement and 
work required from the analyst or the programmer. Automated ana- 
lysis can, in turn, interact with the user and help in creating a 
better and error-free statement of the problem. 

1-2. IDEAS DEVELOPED Iff THE THESIS 

It has been observed that while recognising the need for a 
computerised information system the user is very clear about the 
outputs and reports expected from the system, A simple reason for 
this is the influence these reports and data outputs have on the 
decision making process besides the other benefits of a computeri- 
sed system. At this stage the user may not have a clear idea of 
the process of obtaining these reports. 

In this thesis a methodology is developed for identifying the 
information needs of the user, making reports as the starting point 
for the systematic analysis of the information needs. 

A language for describing reports has been developed with spe- 
cial features for data generation and fonoatting related to the 
reporting medium. A block structure is followed in the language 
to allow structured development of the report description by the 
user. Algorithms are developed to identify data needs from the 
report descriptiens . Input documents being a variation of reports, 
the user can also specify the data variability with the help of 


this language. 
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In business data processing, quite often, the data sets are 
partitioned into a large number of subgroups which undergo simi- 
lar data transformations or processing. A language has been deve- 
loped for describing such data transf ormations. Handling such 
subsetted data sets is a special feature of this language . Algori- 
thms are developed to match the data needs for reports with the 
data availability from input and data transformations, The data 
descripancies, missing data items, and other analysis information 
reported by these algorithms can then be used to correct and modify 
the problem descriptions. 

Algorithms have also been developed to further analyse the 
problem description for design purposes. Procedures for generating 
queries for analysing have been discussed. 

1-3. OUTLIES OP THE THESIS 

Chapter 2 of the thesis gives a survey of the research work 
currently being done in this area. In the first part the data 
oriented user-level languages and the form and power of these 
languages is described. Second part deals with the over all system 
design and some of the implemented systems. Difficulties encountered 
in various approaches have been summarised. 

Chapter 3 of the thesis gives the basics .approach of stating the 
information needs for a system by describing the > re'port requirements. 
Different types of problems encountered in making formal report 
descriptions are discussed. A language is proposed for giving formal, 
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complete and user-oriented report descriptions. Syntax for such a 
language is developed. The semantics of the language is described 
with the aid of detailed examples. An implementation for getting 
data needs from report descriptions, is discussed. 

Chapter 4 of the thesis describes the document and process des- 
cription parts of the system description language. User can directly 
describe the data transformations and data availability in terms of 
documents, so that the data needs and data availability together can 
be used to identify the missing information. A concept of subsetted 
data sets has been developed as the basis of the system description. 
The syntax and semantics of the system description language is des- 
cribed. A generalised update concept and its relation to data cycles 
and data storage is discussed. This concept is incorporated in the 
language for system description. 

Chapter 5 of the thesis describes the different interactive aids 
that can be used for system development if this methodology of system 
description is used. Aids to collect, design and analysis information 
by asking questions from the user are also discussed. 

Chapter 6 of the thesis describes a detailed case-study to 
illustrate the need and the utility of various aspects of the system 
description language. This case study demonstrates the necessity for 
different kind of features in the language and the ease of use of the 


language . 
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Chapter 7 of the thesis summarises the conclusions and discusses 
further research work to he done in this area. 



CHAPTER 2 


AUTOMATION FOR INFORMATION SYSTEMS 

Generalized business data processing was recognised as a re- 
search area in the early sixties [ CDA 59 ] and work was started to- 
wards data system languages and theories of data processing. A 
number of concepts and aids for design and descriptions of such 
systems were developed over the decade [ GOU 74 1 . Around 1970, 
work on this problem was also started by various groups at Michigan, 
Sweden, Project MAC at MIT, IBM Research Laboratory and others. 

2-1 . DIRECTION OF RESEARCH 

Research in this field is focussed on two different areas. 
Automation of system analysis and design is one of these areas where 
a number of systems have been implemented and are undergoing further 
development. ISDOS [ TEI 71] , Hoskyn's system [RHO 72] , Protosystem I 

[RUT 75 ] are seme of the examples which vo.ll be discussed in detail 
later in this chapter. Small commercial software like SAM [ADR 74] 
(system analysis machine), Meta COBOL [ADR 74 ] , CONVERT etc., are 
available which incorporate the concepts of system analysis and data 
representation in a limited sense. However, these will not be dis- 
cussed. 

The second area of research is to develop the interface by which 
the user can describe his information requirements and information 
transformation; in other words the languages for user descriptions. 


9 
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For the purpose of an overall study, the languages that are being 
currently developed may be grouped according to the basic approaches 
taken. Each group will be discussed in later section of this chapter. 
Query-by-Example, HI -IQ (Hierarchical Interactive Query), SEQUEL 
(Structured English QUBry Languages), PORAL and RIL (Representation 
Independent Language), the language for parameterisation of infor- 
mation systems etc., are based on the relational data base concept. 

BDL (Business Definition Language) is for questionnaire driven inter- 
action for building application models. MAPL and OWL are high level 
languages for interactively building models for the world-of-business. 
Different types of naming mechanisms are used in these two languages 
to bui l d up relationships. These two languages will be discussed 
along with the Proto System I. 

ADS (Accuretely Defined Systems), PSL (Problem Statement Lan- 
guage), and TAG (lime Automated Grid), directly follow a data proce- 
ssing approach. These will be discussed along with the other aspects 
of ISDOS, because these have been implemented with ISDOS. Business 
system planning, OSD (Object System Descriptions), IA (information 
Analysis), Systemeering (System Engineering), PIS (Product Informa- 
tion System) are some of the management level techniques, which ore 
partially computerised. These will be discussed together, later. 
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2-2, DATA BASE ORIENTED LANGUAGES 

A number of query languages vfaich provide user interfaces for 
logical selection of de,ta from the relational data bases also pro- 
vide some features for making the queries more readable. The capa- 
bility of these languages is similar to that of DSD-'’ [COD 72] 
described by Codd. The reasonsfor discussing these languages in 
the context of data processing are the following : 

(1 ) Data processing systems are now designed with 
data base concepts, using data base software. 

(2) These query languages are non-procedural in 
nature and user-oriented in their form. Data 
processing languages also seek these two pro- 
perties, 

(3) It is generally understood that a combination 
of fairly complex queries is equivalent to a 
data processing transformation. Dor example, 

SEQUEL as a data definition facility for an 
integrated data base[ OHM 73] is required to 
encompass the functions of a general purpose 
query language to accomplish many of the tasks 
which were previously reserved for application 


programs 
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Limitations of these languages will bo discussed by taking 
DSL-''" as the standard. The form of these languages will be des- 
cribed first and then the capability of these languages will be 
discussed together. 

2-2.1 FORM 0? THE LANGUAGES 

2-2.1 .1 SEQUEL ; It has a block structured form in which, 
by using WHERE SELECT and ERCM clauses the need for range descrip- 
tion is eliminated and by using a block structure the use of tuple 
variables for linking is avoided. This makes a statement more 
natural for a user. SEQUEL is implemented with a model using XRll 
relational memory system with the help of a PL/1 interpreter. 

2-2.1 .2 HIERARCHY CAL LANGUAGE FOR IN TER ACTIVE QU ERIES : 
HI-IQ used as an interface to Data Base Structure Designer [ GER 76] 
is more powerful than SEQUEL due to its hierarchical structure. 

In this the selection is incorporated at every level. Statements 
in HI-IQ are less English-like but the aim of HI-IQ is to make 
statements to set the environment for data base structure design. 
HI-IQ is mentioned here, because of its power of selection while 
maintaining a fairly high level interface. This is also an implemen- 
ted system. 

2-2.1 .3 QUERY-BY-EXMOPLE ; QBE [ZLO 77] : a the user 
Interface for the System for Business Automation. The language is 
relationally complete. It uses a novel idea of using examples of 
concepts as synonyms of concepts in a local context. The concepts 
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here happen to be domain names, relation names, and instances of 
domain-values which are to be treated as separate 'entities# Also 
the external structure of the language is made up of forms. There- 
fore, instead of voriting expressions and statements in a formal 
language the user is restricted to filling up forms. This provides 
ease-of-use and familiarity to user. Nesting of forms is also allow- 
ed. It is obvious that if a process or data to be described becomes 
complex, then description by structure is easier than description by 
instances or examples. Advanced form of this instance concept is 
expected to create problems similar to that of natural language pro- 
cessing. 

2-2 .1.4 m and .PORAL : FORAL [SEN 75] and RIL (Represen- 
tation Independent language) [FEH 73] are higher level interfaces 
of DIAM II system. RI1 is as powerful as the other relational lan- 
guages and has more features far derivations, insertions, etc., which 
have been identified as essential for data manipulation. PORAL is 
the user interface for RIL aiming at allowing the user to represent 
binary and modified binary relationships between names-f or-things. 

It is still under development. 

2-2.1 .5 A Language for Parameter! sat ion of Information 
Systems : This language [IAN 73] gives a special consideration to 
repetitions, volumes and formats of outputs alongwith the other 
features c com on to such languages. For describing formats of 
reports, line-objects and their spatial placement ore considered. 
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It recognises that specific instances of reports do not determine 
completely the semantics of reports. In a system for automatic 
generation of computer programs [PRY 75 1 similar difficulties about 
report descriptions have been observed. Further it has been said that 
in report formatting and specifications of messages, continuity and 
availability of physical space, new page symbols, etc., are to be 
identified. These are frequently data dependent. At this point it 
can be added that sometimes a few data items themselves are depen- 
dent on these conditions. New report specification methods for sol- 
ving these problems are needed. 

2-2.2 CAPABILITY OP IKE LANGUAGES 

To discuss the capability of these languages, in a general wa y, 
DSL- a [COL 72] will be considered a familiar representative of those. 
DSL_ a again is a data base query language. The purpose of this dis- 
cussion is to bring out the basic reason for DSL- ct being found very 
limited for data processing desorptions, let us take two relations. 

P or example 

Relation PARTS lomoins PART /, SUB-PART 
Relation ORLGRS Domains SUB-PART, DATE 

Let us also formulate a query: List all the PARTS where all 
the Sub-PARTs are ordered on the same DATE. This obviously needs 
data selection based on subsetted data set ORDERS subsetted for 
SUB-PARTs of the same part i.e., PART /. For doing this, PIPELINE 
concept with some host language statements will have to be used. 
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In sene other queries one may need image-functions which are 
not supplied in the longuage. Also the need for features like 
PIPELINE and IMAGE functions is there because the language is limi- 
ted to only two quantifiers and These quantifiers are the 

only ones available in the predicate calculus used as the basis for 
DSL- a. A need for being able to partition the data sets into sub- 
sets of tuples and to be able to describe functions of those subsets 
is recognised at this level. This will also be discussed in further 
chapters of this thesis. 

2-3- APPLICATION SYSTEM MODEL S- QUESTIONNAIRE APPROACH 

An interactive business definition system r HAM 75! is being 
developed to describe user needs by interacting with application 
models in a question anwer mode. The language that is used for this 
approach is BDL, (Business Definition Language) which forms the user 
interface for ACS (Application Customiser Services) where experts 
can build models of applications by defining program fragments and 
associated questionnaire. BDL is to allow the user to introduce 
options which have not been offered by the model. 

It can be said that this is an advanced and generalised approach 
to what are currently, application packages. Practicability of this 
method depends on how meaningful is representation, referencing, 
and piecing together of program fragments. Work related to model 
building in this approach is yet to take shape. The language BDL, 
which is not yet implemented, has five components as follows: 
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1 . Document Description Component - DDC 

2. Human Interaction Component - HIC 

3. Device linking Component - DDC 

4. Document Plow Component - DDC 

5. Document Transformation Component - DTC. 

DDC is used to define the structure and attributes of documents. 

It is also meant for defining the format of the document in terms of 
media that will eventually be used for external realisation. It also 
allows definition of domain types like dollars, date, number etc. 

As DDC is based on a line-item concept (one line of the documents), 
it is suitabLe for forms and not for reports. Definition of external 
media and its effects are also not generalised. 

HIC, the human iteraction component allows scope for user deci- 
sions in on interactively executing application. This is often needed 
for manually supervised application, for overriding supervisory 
actions. How HIC can be made a module and not a manifestation of the 
basic development of the application, can be understood only after 
the HIC and the model building process are fully developed. 

DDC is for defining the linkage between the logical media 
described for documents and the actual combination of media used. 
Currently this function is being performed by terminal handling systems, 
written by the user, on generalised definition languages. DDC may .fce at 
a more logical level. 
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DEC is the document flow component for defining the basic 
structure of the application. It graphically represents the docu- 
ments and the organisation units called steps, that use these docu- 
ments . 


ORDER 


, SALES ' 
+ | ORDER 

! (Step) 

\ I 


(document ) 
_ _INVO_ICE__ 

LEDGER 
(document ) 


• BILLING 
1 (Step) ■ 


(cm 
' ' — y 

It deals with steps, paths, documents and fil es. Riles here mean 
sets of documents. Elies are denoted by circles and access paths. 

A step executes when all its input documents are present. Accumulate, 
stream, copy, join (merge by arrival) are various types of step 
commands . It is mentioned that processing within steps, described 
latoi as DIO, is oriented around aggregates and therefore input to 
the steps should be groups of documents whenever possible (though 
groups may be singleton groups). It also expects the user to do 
explicitely all the linking. This suggests that there are difficul- 
ties in recognising and handling parallelism of steps. Real life 
document oriented systems have parallelism as a basic property. 

Then, it is more the form and not the capability of DEC, that is 


document oriented 
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DTC as the document transformation component is the basic capa- 
bility of BDL. DIG statements are like filling up a form under five 
headings of NAME, DOMAIN, GROUP, FILTER, DERIVATION and a heading-less 
space for conditions, whenever needed. The rows actually form part 
of a hierarchy shown by indentations which describes repeating groups 
in the output. Under the name column data items on the output are 
specified. The domain column specifies the name of the group (which 
is the input file name) which generates the data item. Putting TOTAL 
in the name column and one of the name column entries in the domain 
column is also allowed. Hoy/ this can be linked up with the DDC is 
not very clear. Group column can have entries of data items which 
are used for lower levels. This allows very simple subsetting. 

Filter column is for accessing data-items from other files (practi- 
cally a means of accessing master reference files), though only simple 
selection can be done on these files. Derivation column is for 
simple calculation and precoded (for example SUM, COUNT etc) set 
calculations. 

In DTC, the power of the language has been compromised for a 
form-like appearance. Also, the form filling requires a lot of 
understanding, because of the power of language. At present it can 
not be said as to what extent it gives ease-of-use. 

2-4. HOSKYN'S SYSTEM 

This system was implemented in 1 972 on an IBM system using HSL/1 
(Hoskyn's System Language). The system generates COBOL programs 
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fron user statements given in HSL/l . Besides a basic checking for 
undefined elements etc., this system does not perform any design 
activities. It plugs the various names for direct COBOL program 
generation. 

HSL/l is in the f arm of three tables, which are called matrices 
by HSL. These are program/file specifications, record/data specifi- 
cations and condition/action specifications. Linking is dene by 
allotting a column to each program by putting P in the row for that 
program. For files I/O/U etc., are put in the corresponding columns. 
For simple systems it practically does only the laborious work of 
writing data divisions. The same thing could be obtained by properly 
using the copy option of some COBOL compilers. 

2-5* PBOTO SYSTEM I 

Proto System I [RUT 75] is being designed to automate the process 
of i rograming a problem, based on the understanding created by an 
English language discourse, specifically for management information 
systems. In this system, the process of writing programs is modelled 
as a sequence of translators from an English language task specifica- 
tion to machine code. The different levels are described as follows: 

TO: Problem acquisition (English OWL) 

T1 : Global problem solution (OIL -*■ DSSL) 

T2: Algorithmic solution (dSSL CDSL) 

T3 : Computational (CDSL ■+ PL/I and JCl) 

T4 : Compilation and loading (PL/l and JCL machine executable) 
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Specifications of the problem, in t eras of data processing 
functions is available at DSSL level and most of the system. design 
and optimization of this kind is performed at 12 level. Translations 
of the kind TO tad T1 are suitable for custom made applications where 
domain dependent terms are taught to the translator (for example 
level T1 ) by an expert who can represent the informational view of 
the problem while presenting it in domain dependent terms. In a 
very general sense, this is also what a systems analyst does. In 
this case the computer aid available to the analyst or the problem 
expert is a system, where world-of -business models can be built. 

Information on OWL is not available but a related language 
MARL [MAE 73] can be used to discuss the level of model building. 

The basic construct sj^a* relationships, lor example a-kind-of is a 
relationship which describes objects as characteristics of objects: 

ORDER a-kind-of DOCUMENT . Time, activity, data-item, occurrence etc. 
may be some of the basic constructs needed for business models. To 
give an idea., for a very small real life sales system, one may have 
to construct some 4000 concepts before a user's problem In that domain 
may be stated. Levels higher than DSSL may be suitable only for 
package applications. 

Major concepts of DSSL (Detailed System Simulations Languages) leve 
are liming (period), aggregate data objects, computations and initial 
values. Dor computations of subsets, DSSL also gives a few built-in 
functions like SUBSETMAX, SUBSETPLUS, etc. A variable is specified 
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as a combination of variable name, time period and keys. Though a 
variable version of current time cycle of given period and that of 
the previous period is allowed, no other versions rare allowed. Natu- 
rally, this is a requirement for update computations. Precedence of 
computations in DSSL is implicit in data relationships and therefore 
user generated subset functions cannot be represented. This is a 
limitation far general data, processing. Further development of the 
system, however, nay incorporate such f acilities. 

At the design and generation level the system has a simulator, 
a translator, and an optimiser. Translator translates from the 
compact form of DSSL to more algorithmic forms while maintaining all 
the design options. It also computes properties like predicates, 
inputs, outputs, precedence, keys of data items as well as computa.- 
tions. Optimiser does the aggregation of computations as programs and 
that of data items as data sets. To check the multiplicity and 
existence of data items for estimating I/O costs, the optimiser inter- 
acts with the simulator. Simulator dirbctly executes that part of 
DSSL description (about which an estimate has to be made) on initia- 
lised data items. It collects information about maximum values and 
the probabilities that certain predicates will be true. Aggregate 
system behaviour is obtained by executing parts of the system if 
one data item of each type is given to begin the system. 
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At this point it can be said that part of the aggregate infor- 
mations, obtained from the simulator, is at times well known to the 
application user. Interactive aids may be developed to make the user 
give such information because such simulation may become a very costly 
and cumbersome process when developed to its usable level. It may be 
mentioned that op ti miser avoids problems of combinatorial order, by combi 
-ling only tv® processes or two data aggregates at a time. 

2-6 . I SIPS : IHBOHMATION SYSTEM EE SIGN AMD OPTIMISATION SYSTEM 

A system for automatic design of information systems [ 1EI 71] 
has been developed and implemented on UMI7AC 1108, IBM 360 and CDC 
6500 computers. At the user interface it uses TAG [ MYE 63] (lime 
Automated Grid) or ADS [HIM 74] (Accurately Defined Systems). At 
the analysis level it has the problem statement analyser, PSA [HER 74 ] 
with the problem statement language PSL. At the design level it 
has a system optimisation and design algorithm SODA [ HUH 71 ] which 
has two modules ALT and OPT for design alternatives and optimisation 
respectively. The SODA/ALT generates alternatives by using program 
and file structure algorithms. SODA/OPT has algorithms for optimi- 
sation and performance evaluation. 

TAG is a system design aid which analyses the data item relation- 
ships in the frame of time, by accepting information on an input 
output analysis form. All the input, output, and history data sets 
used in the system are listed along with information about the volume, 
frequency, and tine of use and the various data items that constitute 
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the ^et. Bata sets can be given priorities within a particular tine 
cycle. TAG gives an analysis of the use of data items in the increas- 
ing time cycle order. This technique was originated to consolidate 
the information for nanual analysis. 

The ABS technique uses comparatively more structured set of 
five forms. Specifications for inputs, outputs, history, computations 
and conditions are listed on separate forms and the linking of data 
items is established by specifying the line numbers and form or page 
numbers. These forms were also designed for manual system documenta- 
tation. As the capability of ABS is limited to element by element 
processing generally used in sequential systems there is no way of 
specifying the structure of the problem and data. 

SOBA/PSL, the language acceptable to the analyser module of 
SOBA/PSA, is a very high level language for specifying units or modules 
of the system. It has features for naming the parameters of the unit. 
Bor example, units could be inputs, outputs, conditions, process at 
a lower level, process at a higher level, frequencies, and volumes etc. 
It is very suitable for well developed pieces of software or problem 
statement units being handled by different people. It would need 
too many explicit statement s about the properties of modules, for 
the first level descriptions of systems. 

Analysis of the total problem is performed by SOBA/PSA by using 
matrix techniques [BAB 65] for analysing data definitions, timings, 
precedences, and volume etc. It also performs more detailed analysis 
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to generate suitabLe forms of information for design algorithms. It 
gives the error diagnostics hut does not aid the process of analysis 
by directing the user towards expected error areas or towards giving 
more information for design purposes. 

At the design level, the alternatives for design of programs and 
files are generated by SODA/ All and evaluated by using transport 
volume as a performance criteria and using branch and bound methods 
for different CHI's, core sizes, auxiliary memory and file organisa- 
tions. This approach leo.ds to combinatorial problems. A more heuris- 
tic approach may be more usable. 

2-7 • THEORETICAL ANALYSIS Of IKFOKMATIOH - for business organ! zations 

Some approaches to the theory of information systems [ LAD 63] 
are based on the analysis of current functions of the orgard.sa.tion. 
Here, it is assumed that 'functions’ of the firm or the organization, 
must be in action, for it to fulfill its objectives. Defining these 
functions is one way c£ stating these objectives. Generic informa- 
tion system design approach JCHA 74] considers informo.tion needs by 
identifying and analysing all the documents and the data-items that 
are active in the organisation. Systemeering is [LUH 75] another 
direction in which work is being done to analyse the information 
needs of administrative systems, by describing the system in terms of 
material flow and message flow. The language in this case uses a 
graphical method. The procedures for doing information component 
analysis and information precedence analysis etc. are being worked out. 
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At present it can be said to bo a fomaL method of describing 
the basics of the business functions. The problen of isolating 
the information flow for decision Malting and organi sr ti onal con- 
trol and thon representing it in an accurate way has yet to bo work- 
ed out in these appro schos. 

2-8. COHCLUSIOI'TS 

Characteristics and developments of different systens which 
have been discussed in the previous sections of this chapter arc 
suna.rized in Table 2.1 and Table 2.2. Description, analysis, and 
design of information systens for business data processing are very 
much inter-related. It has been seen that development of one stage 
in isolation, limits the capability of other stages. It is felt 
that an integrated approach will prove more successful, A few ob- 
servations made at the user interface level may be reitcro/ted as 
f ollows : 

(l ) Ease-of-use may be enhanced by making the environment 
interactive, end the language more like English. However, the 
latter nay pose semantic difficulties and therefore atleast some 
commonly used associations related to data may be introduced. 

( 2 ) Description languages should be more data oriented in the 
sense of dealing with sots and subsets of data. 

( 3 ) Beports^ messages need noro complete and detailed descriptions 
as they are the major vehicle of communication between the user and 


the infomation 
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Systems analysis is more mechanical than itelligent at present. 

It should he recognised that the main 'ehortcomings of the problem 
descriptions creep in when the user tries to make a data oriented 
statement while his mental model is still materialistic, for example, 
one does not remember while describing sales, to update the store for 
commodities which have been sold out though this may not he„ppen while 
describing stores inventory or accounting. The analysis should also 
guide the user in this sense. 

Techniques of matrix algebra and simulation etc., are currently 
being used for system design. Heuristic approaches may be more work- 
able. Then the user describes different business functions, the 
organisations and the sequence of descriptions tends to be similar to 
the division and arrangement of working in the organisation. Scope 
of changes in the information system in future due to ommission or 
changes in the needs will be very much related to this inherent 
structure and systems can be made more adaptable if the inherent 
problem structure can be put to use in design. 
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TABU 2-1 . Systems for Design and Description of Information 

Systems 


System 

Proto 

System 

I 

ISDOS 

Hoskyn' s 
System 

Application 

Questionnaire 

Data Base 

Oriented 

Systems 

languages 

OIL , MAPI 

ADS, TAG 
PSL 

HSL/1 

BDL 

QBE,POEAI 
EH, SEQUEL 
HI -IQ 

Type of 
language 

Engli sh- 
like 

Data Matrix 

Processing 

Porm Pro- 
cessing 

DSL- 

System 

De scrip- 
tion 

Model Input, Out- Associa- Model build- 

building put, process tions ing by app- 
using relation- of pro- lication 

binary ships of grains question 

relation- small units files naive 
ships and data 

by mat- 
rices 

Queries 
and data 
manipula- 
tion 

Method of 
analysis 

Cross 

check- 

ing 

Cross 

checking 

Cross 

checking 

Hot known 

Not 

relevant 

Selection 
of Design 
Alterna- 
tives 

Simula- 

tion- 

based 

Combina- 

torial 

genera- 

tion 

User 1 s 
problem 
state- 
ment 

Not known 

Not 

relevant 

Implemen- 

tation 

Yes 

Yes 

Yes 

Not known 

Yes 


(continued) 
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System 

Proto 

System 

I 

ISDOS 

Hoskyn' s 
System 

Application 

Question- 

naire 

Data Base 
Oriented 

Being 

Develop- 

ed 

further 

Yes 

Hot 

known 

Ho 

Hot known 

Hot 

r el evant 

Basic 
aim 
of the 
system 

Genera- Handling 
lised and gene- 
inventory ration of 
model large 

software 

Genera- 
• tion of 
small 
data pro 
cessing 
systems 

Generali- 
sed appli- 
cation 
- package 
building 

Data defini- 
tion and 
manipula- 
tion for 
queries 

Existing User's 
problems model 
build- 
ing 

Time com- Limited 
plexity capabi- 
of design lity 

Assembling 
the model 
together 

Trimi t &c\ 
query/prob- 
lem formula- 
tion 



Table 

2-1 (continued) 


TABLE 2-2: 

. Data 

Base Oriented Languages 



language 

Query-by -Exampl e 

SEQUEL 

BOEAL/EIL 

HI-IQ 

Implemen- 

tation 

System for Busi- 
ness Automation 

System E DIAM II 

Ell only 

Data struc- 
turiser 

Bonn, of 
the lan- 
guage 

Bona, filled in 
with examples 

Block English 

structured like sta- 
query tements 

(in POEAl) 
queries 
(Eli) 

Hierarchical 

query 

statements 

y 



CHAPTER 3 


DATA NEEDS POR INFORMATION SYSTEMS 

Use of an integrated information system introduces a change 
in the information flow within the organisation. Different types 
of information may be available from such an information system, 
such as, usage reports which help in the execution of functions; 
statistics or status reports for checking and control; study re- 
ports in response to queries etc. How much of such information 
can be useful for the organisation and what it implies in terms 
of diverting information to the machine and how much it costs 
has to be visualised. Therefore the role of the information sys- 
tem has to be well understood before the inf ormation needs can be 
described. 

3-1 . IDE MIDIC ATI ON OP INFORMATION NEEDS 

Information for administrative control is used in the form 
of documents and reports, whereas, other systems like real time 
systems and control systems, channelise information, more often by 
message display, transducer and converters etc. The methodology 
developed in this thesis is based on the fact that people use in- 
formation in the form of documents and reports of various types. 

Hie primary aim of an information system is to provide such reports. 
If the requirements of these reports are very well known, by way 
of their content, and form, then the user's problem, i.e., the 
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r equirement s of the information system, can be veil stated. This, 
in turn, may be utilised to find out the processing and data re- 
quired to solve the problem. 

In this way reports also limit the user's expectations from 
the information systems to whatever may be obtained in the form of 
reports,, This forces the user to set the degree of ambition of the 
design of the system before going into the details of processing and 
design. Gross requirements about the environment of processing, 
types of outputs devices needed, etc., also emerge at this sta&e. 
Therefore the role of the information system becomes well identified 
at the beginning of the system development cycle. 

A formal description of the problem of information system de- 
sign is needed before the computer can be used for solving it. 
Different methods of such descriptions like model building etc. 
have been discussed in Chapter 2 alongwith the problems associated 
with those methods. A simpler, but otherwise powerful approach, is 
being developed in this thesis where a description of the outputs 
or the reports, will be treated as the basic problem statement. A 
block diagram shown in Figure 3-1 describes the approach. 

Reports can be fully described in a language which will be 
discussed in the next section. Such a formal description is analys- 
ed to find the data needs for all the reports. User can describe 
the input information and the required information processing, i.e., 
the transformations, in a data oriented language which will be 
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discussed in the next chapter. This is compared with the data needs, 
and any discrepencies or missing information is brought to user's 
attention. This process is repeated till a consistent and complete 
description of the information system is obtained. 

3-2. REPORT DESCRIPTION LANGUAGE 

Data in reports is formally recorded data in the context of 
information system design and is different in nature from informally 
recorded reports. Type of such data may be different such as numbers, 
words, pictures, lines, colours, signs, crosses, tick marks, seals 
and stamps, punches etc. Special requirements of non-alphanumeric 
data are not being considered while discussing the structure of 
reports. 

3-2.1 STRUCTURE OP REPORTS 

Reports have much more structure than messages, forms, regis- 
"ters, and other paper documents. Display of information on reports 
or documents has three important aspects : 

(l ) The actual instance of the data, its value and size 

(2) Name of the data item which can uniquely identify 
the data for the object system. 

(3) Heading or a name for relatively local context. 



t M essages 

- ■ -Eorms/Pages/Documents 


I Reports having a structure 

j 

- over lengthwise continuity 


Eigure 3-2. Different Type of outputs. 
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In the form oriented report languages or descriptions, such as, 
BEL or ADS, the dichotomy of data and its format is such that it 
tends to restrict at least one of the three, i.e., the data instance, 
data name or data heading. For example, in report description forms 
of Accurately Defined Systems, the relevant data items have to be 
associated with the format by linking up of line numbers in the forms. 
In report program generators, control breaks for certain data items 
is the only kind of structure that can be incorporated. In Business 
Definition Language, simple hierarchical structure of data items is 
used. Therefore a language is needed which has a comparatively free 
format for structuring data definition and format together in a way 
suitable for business systems. 

Business systems have data which records properties of large 
sets of similar items. A unique name for selected data is not 
explicitely available and therefore it is made up by attaching 
qualifying names T/hich belong to more aggregate levels. For example 
if there are 20 values for ORDEREB-QUANT ITY then one value may be 
expressed by ORDERED-QUAUTI T Y of a COMMODITY for a CUSTOMER. As the 
heading has limited expressibility, structure is given to the report 
so that a qualifier, common to a number of instances, may be needed 
only once. The user is, often, very specific about the format. 

For these reasons it can be said that a language which supports 
hierarchical naming of data will be more suitable for report descrip- 
tions. The language described in Section 4 of this chapter is based 
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on a block structure concept which can maintain hierorchy of levels. 
This hierarchy is also utilised for effective data naming. Since 
the semantics of the report may not be completely determined by 
specific instances of the reports, it can be described along -with 
the structure. Here the semantics of the report means conditional 
appearance and formatting of data-items. For example, if the 
’description 1 is to be printed only when first time the 'code' 
appears on our output, or when for selected values of data items 
special action is to be taken. 

Example 3-1 illustrates a situation where report is selection 
based. Though the syntax of the description language will be in- 
troduced in later sections of this chapter, the example makes use 
of the language. 

3-2.2 STRUG TUEE AHD THE MEDIUM OF REPORT 

To isolate regions of cannon qualifiers of data and to get 
speed of referencing for those who are to use the report; continuity 
and availability of physical space, line and column spacings, inden- 
tations, new pages etc., are to be identified. The syntactic struc- 
ture of the formatted report is captured by the spatial placement 
of lines of data. Both these are data dependent. Therefore some 
method of synchronising the conditions on the medium of reporting, 
or the output device and the data being put on it, should be available. 
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REPORT ON INVOICE EDITING 

PAGE 1 ! 

PRODUCT 

INVOICE 

CALCULATED 

PRODUCT 

MAXIMUM 

DISC (UNT Cap', CENT 

CODE 

NO 

VALUE 

VALUE 

DISCOUNT 

VALUE 

0513 

10 

53.5 

53.0 


COMCGNT-1 

0600 

1 



10 

1 2 COMMENT-? 

0713 

3 

60.0 

65.0 

9 

15 COMMENT-1 






COMMENT- 2 

0613 

6 

23.5 

23.0 


CCMHENT-1 

♦ * • * 

• * 

* * » * 

» « * * 

* « 


m • » • 

* • 

• • * * 

• 009 


— - - ~ 


POR EACH DAY REPORT INVOICE-EDIT 
EDOM DATA SET INVOICE-AUDI T : S 

BLAHK 12, 'REPORT OIT INVOICE EDITING," PAGE-NUMBER 
NEW-LINE, HEADING-LINE-1 , NEW-LINE, HEADING-LINE- 2 
EOS EACH OE THE INVOICE-AUDIT DEGIN 

EOS DISC OUST- ABOVE-MAX = 1 OS VALUE-DISC] iEPANCY-COTJNT = 1 BEGIN 
NEW-LINE, PSODUCT-CODE, INVOICE-NO 
EOS VALUE-DI SCSEPANC Y-CO UNT = 1 BEGIN 
CALCULATED-VALUE, PRODUCT-VALUE END 
EOS DISC OUNT-ABOVE-MAX = 1 BEGIN 

MAXIMUM-DI SC OUNT , DISC OUNT- VALUE END 
C CMMENT-1 

EOS COMMENT- 1 = BLAJTK BEGIN COMMEHT-2, END 
EOS COMMENT-1 ^ BLANK AJTD COMMENT- 2 / BLANK BEGIN 
NEW LINE, COMMENT-2 END 
EOS NEW-PAGE BEGIN PAGE-NUMBER END 
POPSLT HEADING— LINE-1 EROM 1 VALUE "PRODU"- 
-"CT INVOICE CALCULATED PRODUCT MAXIMUM DISCOU1TT COMMENT '• 

HEADING-2 EROM 2 VALUE "CODE NO."- 

-" VALUE VALUE DISCOUNT VALUE" 

PRODUCT-CODE PROM 2 SIZE 4 INVOICE-NO PROM 12 SIZE 2 

CALCULATED- VALUE PROM 24 PICTURE 99.9 PRODUCT-VALUE PROM 36 PICTURE 99.9 

MAXIMUM-DISCOUNT PROM 45 SIZE 2 DISCOUNT-VALUE PROM 55 SIZE 2 

COMMENT PROM 60 SIZE 10 

OVER 



36 


Spec'.al features have been developed in the report description lan- 
guage to sense the conditions and to control the reporting device in 
a logical sense. This is done by taking paper as the output medium 
in general and incorporating a two dimensional forward control on it 
and associating a current status with it. 

A simple example of this is viien a variable numbs r of lines 
appear on an invoice with a three line 'end of invoice 1 procedure; 
suppose the end- of -invoice part is to be printed at the end of the 
page unless the last cage of the invoice contains only end -of -invoice 
data the language is shown in Example 3-2, 

Example 3-2 * 

REPOR T I1W0ICES ERCM PAPA SET BTT.T, :S 

FOR EACH CUSTOMER OF BILLsS ' BEGIN 
NEW-PAGE, CUSTOMER 
FOR EACH* OF THE BILL:S BEGIN 

MEW-LIKE, BILL-MO, AMOUNT, END 
FOR LINE-MUMBER 1 BEGIN ' 

3 LINES BEFORE END-OF-PAGE END 
"END OF INVOICE" 

NEW LIME, "SIGNATURE" 

NEW LINE, ", » 

OVER 

3-2.3 DATA AND THE REPORTING MEDIUM 

From the report point of view, there are two types of data items 
present on the report. 

1 , Those which are directly obtained from the data base 

2. Those which are dynamically dependent on the synchroni- 
sation of format with other data it ems . 



37 


A simple example is that of carry-forward-totals used in 
accounting applications. Such items are included in the reports 
to give speed and ease of referencing to the people. To give a 
different example, in listing out customer-wise orders, only for 
the first order, the customer name need be printed unless it is 
o. new page. Such requirements are there to reduce the redundancy 
of information. 

If the format description of reports and the processing of 
the report-information are described in a segregated manner then 
such situations are difficult to handle. In this approach, status 
conditions of the reporting medium and generation or selection of 
data items can be done together. 

Example 3»3 

REPORT EMHj OYEE-DETAIL PROM DATA SET EMPLOYEE 

POR EACH DEPT-NO BEGIN ~ 

NEW-PAGE, LEPT-HEABING, DEPT-NO 
NEW-LINE, "DEPT-TYPE" ,r DEP-CLASS » 

NEW-PAGE, MAKE CARRY-PORWARD-BALANCE = 0 
POR EACH NEW-PAC-E BEGIN 

PAGE-HEADING, PAGE-NUMBER, CARRY-POR\\ r ARD~BAL END 
POR EACH EMPLOYEE-NO BEGIN 
NAME, CLASS* ADDRESS 
NEW-LINE, BASIC, NET 
ADD NET TO CARRY-PORWARD-BALANCE END 
POR EACH 3 LINES BEPORE END-OP-PAGE BEGIN 

"TOTAL-BALANCE'’, CARRY-PORWARD-BALANCE END 
PORMAT PAGE-HEADING VALUE 'EMPLOYEE-DETAIL " CARRY-PORWARD-BAL 
SIZE 8 ADEPT-HEADING VALUE "THE DEPARTMENT " NAME SIZE 10 CLASS 
SXZE 1° ADDRESS SIZE 10 BASIC PIC 9(4). 99 
NET PIC 9(6). 99 
OVER 
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3-3 . DESCRIPTION OF THE LANGUAGE 

The report description in the proposed language starts by naming 
the report and naming a data stream from which the data is to be se- 
lectively put on the report. The user at this point need not visua- 
lise the exact data content of the data stream. It is more for the 
sake of establishing a local reference to a data set which could 
eventually be used for report generation. Also, it need not be a 
defined data set, as the reports are the starting point cf the 
description. The logical structure and the physical format of the 
report are then described in an interleaved manner. The language 
is a free format language. 

3-3-1 FEATURES ECR STRUCTURE DESCRIPTION 

The report structure may be developed in a step by step fashion. 

A report may be described in terns of subreports and group names may 
be usod for data items which are functionally similar. Eor example, 
EARNINGS : BASIC, D.A., HRA etc. Such groups and subgroups may be 
described at a later stage. This is illustrated in the Example 3-4* 

Detailed description is given in the form of blocks and nesting 
of blocks at different logical levels. This facilitates special 
descriptions at the beginning and at the end of a group of data* In 
present report generators a logical level may be created by a change 
in the value of a data item. With this kind of block structure 
different type of conditions may be used to create a level. Depending 
on the condition which created a level different description for the 
report at that level nay be given. 
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Example 3-4. 


REPORT COINAGE-PAGE PROM DATA SET COIN-RECORD 

NEW-PAGE, PAGE-NUMBER, HEADING-1, COIN-1, COIN-2, COIN-3, OOIN-4 
NUW-LINE, C OIN-VA1UE-HEADING, COIN- VALUE OCCURS 7 TIMES 
TOTAL OP COIN-VALUE, 

NEW-LINE, ALL " " 

OVER 

REPORT DEPT-C OIN-REC ORD 

PROM DATA SET DEPT-CO IN-RECORD 

POR EACH DEPT-C OIN-REC ORD BEGIN 

COINAGE-PAGE REPORT USING ( DEPT-CO IN-RECORD POR COIN-RECORD) END 
COINAGE-PAGE REPORT USING (TOTAL OP DEPT-COIN-RECOHD POR COIN-RECORD) 
OVER 


POR EACH MONTH 
REPORT COINAGE 

PROM DATA-SET EMPLOIEE-C CINAGE 
PCR EACH DEPT BEGIN 

POR DEPT 32 BEGIN MAKE PAYPOINT OP EMPLOYEE-COINAGE = 1 END 

POR , DEPT 40 BEGIN MAKE PAYPOINT OP EMPLOYEE-COINAGE = 2 END 

POR DEPT 61 BEGIN MAKE PAYPOINT OP EMELOYEE-C OINAGE = 3 END 

POR DEPT 99 BEGIN MAKE PAYPOINT OP EMPLOYEE-COINAGE = 4 END ! 

END 

POR EACH PAYPOINT BEGIN 
POR EACH DEPT BEGIN 

DEPT-COIN-REC ORD REPORT USING (EMPLOYEE-COINAGE POR DEPI-COIN-RECORI 
END 

CCINAGE-PAGE REPORT USING (TOTAL OP EMPLOYEE-COINAGE POR COIN-RECORD) 
END 

COINAGE-PAGE REPORT USING (TOTAL OP EMPLOYEE-COINAGE POR COIN RECORD) 

NEW LINE 
ALT. " 

OVER “ 


3-3.2 FEATURES POR DATA SELECTION 

Format of the report my be dependent on the properties of data. 
In ADS and report generators this is incorporated to the extent of 
control breaks and totals. In our language it is possible to specify 
properties of data in greater detail. For example if data item 1 is 
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non- zero only then certain other data items should bo put on the 
report. A more important aspect of data selection, which is sub- 
setting of data, will be described in detail in the next chapter. 

Data selection becomes more important when certain kind of 
processing for data generation has to be described specially in the 
context of reports due to its relation with the reporting medium. 

3-3.3 FEATURES BELATED TO DEPORTING MEDIUM 

Status conditions of the reporting medium or the hardware, like 
HEW-PAGE, END-OE-PAGE etc., can be used alongwith the data conditions 
to format the report. Control of the reporting medium is also needed 
for formatting for selective positioning of data on paper and this 
may be described along with the data, items and other processes. 

It helps in making the report description complete and independent. 

3-4. SYNTAX OE THE LANGUAGE 

Syntax of the elementary form of the language is being given here 

to aid the description given in the above sections. 

<REP0RT> : := REPORT < REPORT-ID > <DETAIL > OVER 
< DETAIL> ::=: <STRUCTURE> < FORMAT >| <COPY-STATEMESTT> 

STRUCTURE > : := <DAIA-SET-CMUSE ><PROCEDURE-BLOCK> 

<REP0RT-ID> : := <VARIAELE-UAME> 

<DATA- SET-CLAUSE > : := FROM DATA SET < DATA-SET-DAME > 

<DATA-SET-RAME > : := ^ARIAHLE-CTAM^MID 1 < VARIABLE-NAME >< TIME-INSTANT" > 
<P ROCEDURE-ELOCK > : := <SIMPLE-PROCEDURE > | 

-Pqr<COTDITION> BEGOT <PROCEDURE-BLOCK> END [ 
<PROCEDURE-BLOCK > ^PROCEDURE-BLOCK > 
<BIMPLE-PROCEDURE> : := <REPORT-HARD7&RE-PROCEDURE > 

<DATA-ITEM-STROTG > 

<CA1CULATI OF-STATEI/EMT> 

< REPORT-CALL > 

<C0NDITI0N> <REPORT-HARDWARE-CONDITIONS > 

<DATA-SET-ELEMERT- SELECTION > 

<SIMPLE-DATA-CONDI TI 0NS> 
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< REPORT-CALL > ::=< VARIABLE-NAME > ' REPORT |< COPY ST TE71ENT > 

< USING-CLAUSE > : := <EMPTY > | USING REPLACE-CLAUSE 

< REPLACE-CLAUSE > : := < REPLACE-CLAUSE > < REPLACE-CLAUSE > | 

< ALPHA STRUTG> FOR < /ALPHA STRING > 

< DATA-ITEM-STRING> : := <LATA-ITEM > [ <DATA-ITEtt> < DATA-ITEM-STRING> 

< DATA ITEM> : := <SIMPLE-DATA-ITEM> | < CALCUL ATED-DATA-ITBM > 

< CALCULATED-DATA-ITEM> : := TOTAL OP < VARIABLE-NAME > | 

COUNT < VARIAELE-NAME > AS < VARLABLE-NAME> ] 
MAX < VARIABLE-NAME^ AS < VilRIAELE-NALIE> | 

(other standard functions may he added) 

< SniPLE-DATA-IIEM> : := < SINGLE-DATA-I TEM- | <7Jffi£Y-v -DATA-ITEM !> 

< SINGLE-DATA-I TERE> : := < VARIAELE-NAME > |<LITERAL> | <0THER-DI > 

< ARRAY-DAIA-ITEM> : := < VARIAELE-NAME > OCCURS < INTEGER > TIMES ' 

< CALCUL ATI ON-STATEMENT> : := MAKE < VARIAELE-NAME > =< SINGLE- DaSA-ITEM> 

(assignment ) 

ADD < ADD-CLAUSE> | 

COMPUTE < COMPUTE-CLAUSE > | 

INCREMENT < INC-CLAUSE > | 

MULTIPLY <JIDL-CLAUSE > 

< REPORT-HARDWARE-PROCEDURE > : s= NEW-PAGE | NEW-LINE 1 PAGE 1 

SKEP-TO-CHANNEL < INTEGER > | 

SKIP-TO-LINE < INTEGER- 

SKIP < INTEGER > LINES 

APTER < INTEGER > LINES I < INTEGER> 

BEFORE END-OP-PAGE | 

SET-PAGE <INTEGER> LINES! 
SPECIAL-FORM-STATI ONflRY T REPRINffl-LINE I 
END-OP-PAGE I 

< INTEGER > COLUMNS OP SIZE < INTEGER 
PROM < INTEGER > | 

< REPORT-HARD YfARE-C ONDITI ONS > : PAGE | NEW-PAGE | LINE< INTEGER > I 

CHANNEL < INTEGER > | END-OP-PAGE | 

< INTEGER> LINES BEPaESTEISL'OPAPA&E I 
PAGE-COUNT < INTEGER >j 

< INTEGER;, TO < INTEGER > LINES BEFO RE 

< DATA-SET-ELEMENT-SELECTION> : := < ll^^VALUE^^ONDiTioiJ > ^RANGE-CONDITION > 

| < UNI QUE- VALUE-C ONDI TI ON > | 

< UNIQUE- VALUE-CONDITION < SEQUENCE > 1 
< ELEMENT-CONDITION > 

< GI VEN-VAL UE-C ONDI T ION> : := EACH < VARIABLE-NAME > = < SINGLE-DATA-I TEM > 

< UNIQUE-VALUE-CO NDITI ON > : := EACH < VARIA BLE -NAME >*“ 

< ELEMENT-CONDITION > : := EACH _OP < DATA-SET-NAME > | < INGEGER > TIMES 

< RANGE-C ONDITI ON> ; ;= EACH < VARIABLE-NAME- = ( < RANGE > ) ~ 

< RANGE > : := < RANGE > , <RANGE> | * < SINGLE-DATA-ITEM > 

® PROM < SINGLE-DATA-ITEM > TO < SINGLE-DATA-ITEM > 

< SEQUENCE > ::= ASCENDING| DESCENDING | SEQUENCE ON < VARIAELE-NAME> <SEQ- 

< SIMPLE!-DATA-CONDITION> : :=< SIMPLE-CONDITION ">T " UENCE> 

< SIMPLE -DAIA~CONDITION>< L OGIC AL-RELA TI ON > 

-< SIMPLE-OONDIT ION> 

< OTHER-DI $ PAGE-NUMBER I PAGE-C CUNT I LINE-NUMBER | <P CRMATTED-DI > 

< P QRMATTED-DI> : := < VARIABLE-NAME > (PICTURE) | SPACE ( INTEGER )_ 
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< LOGICAL-RELATION > : := AND | OR) NOT 

< SXMPLE-C CNDITION > : := < VARIABLE-NAME>< RELATION < SINGLE-DATA-ITEM > 

< RELATI ON > ::= >|<| = j NOT = I &\ £ I > I < 

<EORMAT> FORM AT <E CRM AD-DETAIL > - “ 

< E OEM AD-DETAIL > : := <LINE> | < LINE> < EORMAT-DETAIL> 

<LINE> : := < DATA-REEERENCE> jc DATA-EORMAT > | DATA-POSITION 

< LATA-EORMAT > : := < PICTURE-CLAUSE > (cVALUE- CLAUSE > 

<MTA-REEERENCE> : := <VARIABLE-NAME > | 

<VARIABLE-NAMS-> (<UOSITION-IN-REPORT> )_ 

< POSITION-IN-REPORT >: := <INTEGER> 

< PICTURE-CLAUSE > : := AS IN COBOL] SIZE < INTEGER > 

< VAL UE-CLAUSEt- : := VALUE ' <LITERAL >| VALUE < TIME-INSTANT > 

<POSITI ON-CLAUSE > : := EROM CHARACTER < INTEGER > EROM< INTEGER >| 

EROM COLUMN< INTEGER > 

< VARIABLE-NAME> : := cLETTER > <REST-OE-THE-NAME > 

< REST-OE-THE-NAME > : :=< LETTER. | <DIGIT> | <REST- OE-THE-NAME > <RE ST-OE-THE 

NAME > 

< INTEGER> <DIGIT><DIGIT>< INTEGER > 

< DIGIT > : := 1/2/ .. . / 9/ 0 

<LITERAL> <ALPHA-STRING > " | &LL "< ALPHA-STRING > " -NON-PLANK 

BLANK | ZERO | SPACE~ "| SPACES I ZEROS KLITERAL>- -<LITERAL> 

< ALPHABET > : :=| A | B | C | . , ... | <DIGIT> 

< ALPHA-STRING > : := < ALPHABET >j; ALPHABETS < ALPHA-STRING > 

< LETTER* A| B | C| ... \ Z 

3-5. IMPLEMBNTATI ON EOR DATA NEEDS EROM REPORTS 


Erom a report description given in this language, data requirements 
can be derived. A subset of the above syntax has been implemented, using 
a software package to generate the processor. The syntax is described 
in a prescribed way. The semantics is described in the form of COBOL 
procedures to be executed for the c arre sponding grammatical entities. 

The software package generates a COBOL program, incorporating the given 
semantics and syntax, complete with a generated scanner etc. Once 
the report description is found to have correct syntax the data needs 
are derived by going through the hierarchical relationships between 
various data-items. Data-items having constant values or values • 
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generated in the course of the development of the report are dropped 
from the analysis. Data needs are described in the form of relations 
giving keys and attributes. Various drvfca-i terns having the same keys 
for a unique identification are put as attributes in the same relation. 
Data-itens occuring as keys for some attributes may themselves be 
attributes in other relations. 

Here, attributes a.re those data-items which are to appear on the 
report. Keys are those data-items which are used to select and iden- 
tify relevant values of attributes and data-items, at various levels, 
from a large set of data. Data needs for all the reports can then be 
analysed together. The part of the program which ms input to the 
package is given in Appendix 1 

When a suitable system software and configuration is available this 
implementation can be easily modified to change the input to inter- 
active mode. In tha.t case the errors can be pointed out and corrected 
on the spot. The output can be presented to the user in a more readable 
way by naming relations using keys. For example 
Relation : 01; keys : CUSTOMER; attributes : HAME, ADDRESS 
Relation ; 02;keys : C0M40DITY, CO ST attributes : SIZE, COLOUR, ERA HD 
Relation display: 

CUSTOMER-DETAIL (UAME, ADDRESS ) 

COMMODITY-COST-DETAIL (SIZE, COLOUR, BRA HD ) 
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3-6. CONCLUSION 

In conclusion it can be said that identifying user' s information 
needs is the first step towards information system design and analysis. 
It is very important to set the scope and the necessity of the data 
requirements. By identifying the reports that will be expected from 
a system the user implicitly states the scope of the required system. 

If the reports can be described in clear and precise may at the user's 
level then the basic data needs can be derived. User has familiarity 
with reporting and if an easy-to-use language with good description 
power is available then a specific start can be mo.de towards informa- 
tion need identification. 

Once an interactive report language processor is available it can 
be extended to help the user in formatting the reports and it can help 
the system analyser in interpreting user's needs in greater detail. 

The report description method developed here has a very special 
advantage of not being a language in isolation but it identifies with 
the further development of a user level data and document description 
language . 

It also has special features where reports which have to be 
related to the reporting medium or the reporting hardware can also 
be completely described. 

The data selection feature can be extended. For example arithmetic 
expressions on data items may be used for selection within the basic 
structure, heady made features may be increased or reduced to get ease 
of description without curtailing the power of description. 



CHAPTER 4 


DATA DESCRIPTION FOR INFORMATION SYSTEMS 

There are many approaches to descriptions of information trans- 
formations required for the target information system. In the model 
building approach the user has to build up concepts about actions which 
constitute the real life system. The user, in general, may have to 
build up a very large number of concepts and for handling real life 
systems this method can become very cumbersom. In the questionnaire 
approach a generalised model is developed for the user and a support- 
ing questionnaire, pertaining to the problem area, interacts with the 
user to make the necessary changes for adapting the model for the 
user. This method can be used for highly specialised applications. 

Also to assemble the system again, in the light of the change initia- 
ted by the user is not always possible. In this chapter a different 
approach is proposed for generalised information system descriptions. 

To describe an information system it is not necessary to describe 
all the functions and the entities of the organisation. Information 
system has a specific role in the organization which is that of selec- 
tive data handling. Generally a well structured description of the 
involved data is not available. A purely non-procedural description 
of data only in the form of a set of predicates or properties is very 
difficult. The user can, however, give a description of how he can 
get what he wants through repetitive selection of data. In other words, 
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the user can describe the required information system by giving one 
logical design or statement of data processing. Then, any descrip- 
tion ? which can give rise to equivalent data transformations can 
be used to describe the system and to generate technical designs of 
the system. 

Information systems which are data processing oriented and do 
not necessarily have a library-like function deal with few different 
types of entities and a loxge number of functions related to such 
entities. Such functions give rise to abstract concepts as properties 
of these entities. For example SALES and COSTING, are concepts which 
are generated entities and are entities formed by data associations. 
Therefore instead of clear cut properties and concepts there are mainly 
data-associations to be described. 

In additional problem exists due to large cardinality of data. 
Eifferent occurrences cannot be provided with names. Therefore, ins- 
tead of directly addressing data, data selection has to be used to 
limit the scope of names in a local sense. For example, data about 
STUDENTS with GRADE = 9 may be selected for the purpose of describing 
other properties for these STUDENTS System does not maintain different 
names for selecting students with different grades. 

4-1 . STRUCTURE CE DATA TRANSFORMATION 

In describing information transformations, there may be calcula- 
tions, groupings, assignment or conditions. Data can be visualised 




47 


in the form of tables where rows represents the entities or concepts 
and columns represent the properties. For example, in conventional 
sequential systems there ore fields and records. If there are a large 
number of entities and a small number of properties there are more 
rows and few columns. Entities are divided into classes and aggregate 
or overall properties of such classes are derived. For example, 
total quantity of order for a commodity may be derived by aggregating 
all the orders for the commodity. The divisions into such classes is 
done according to properties or the values of the columns. If a 
property can take a large number of values then such classes are again 
large in number and can not be identified by names. For example, if 
ORDER’S have two properties such as TYRE and CUSTOMER-NAME of ORDER'S. 
TYPE can take values "TEMPORARY" or 'PERMANENT" and CUSTOMER-NAME can 
take any value from a set of (say) 100 names. Then based on TYPE, 
ORDER'S can be named as TEMPORARY-ORDER ' s and PERMANENT-ORDER 1 s . Based 
on CUST OMER -NAME, no such names can be given even if name-wise sets 
have to be referred to. Therefore, it becones necessary to have two 
type of features in an information system description language. One 
is that of subsetting the entity set into classes. The other is of 
being ale to perform aggregation of information or of describing 
functions of subsets. 

However, the functions cf subsets are generally describable by 
using simple calcul rtions. Aggregation of information is not like 
that of statistical processing. The difference is there because the 
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information developed by the information processing system is normally 
used by people at different levels in the organisation. Whereas, 
results of statistical processing are normally used by small groups of 
trained people. 

4-2. DATA SELECTION AHD SUBSETTING- 

Data selection and data subsetting are two features which have 
been incorporated in the language described here. Depending on the 
values of a property, a set may be divided into classes which are 
functionally similar. Dor each value of that property one instance 
of the class or the subset of data is generated. This is done by 
using "EACH" function. These classes have to be identified or made 
available for generation of aggregate information and for further 
data selection. Eor example, once the STUDENT'S have been divided 
into classes according to GRADE, then value of GRADE can be used to 
identify the subset of students in the GRADE. GRADE becomes a sub- 
set property. This is achieved by using a block structure. A block 
is a sequence of procedures to be done on all sets which are input to 
the block, considering one set at a time. The procedures may be of 
the following type - 

(1 ) Data subsetting procedures 

( 2 ) Data selection procedures 

( 3 ) Data generation procedures (data generation by calculations 
and assignment). 
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4-2.1 DATA SUBSETTING PROCEDURES 

Hie basic tool towards the aggregation of procedures is provided 
by the data subsetting procedures . A subsetting procedure operates 
on a set of data. If the set is input to such a procedure the whole 
set becomes available to the procedure at a time (conceptually) though 
the procedure may operate on elements one by one. The procedure out- 
puts a number of subsets each having some elements. It also attri- 
butes sane properties to each subset. Each property has one value 
for one subset and may also be used to further identify the subset. 
Such subset properties then become global properties at subset level 
and in concept are no more associated with the elements of the subset 
on an individual basis. 

To be able to operate on these subsets a number of any kinds of 
procedure s&transf ormations may now be written in a block at a level 
lower than that of the subsetting procedure. Eor these procedures the 
subsets are made available (one subset at a time) along with all its 
elements. These procedures may use only subset properties and not in- 
dividual element properties unless the subsetting has been done to 
an element level. 

Examples : 

FOR EACH ORDER-NO OF ORDER :S 

FOR EACH OF ORDER :S 

FOR EACH TORDER-NO. ORDER-DATE) OF ORDER :S 
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The above three examples, subset the set of all ORDER'S into 
classes of ORDER'S, with same ORDER— NOs, having ORDER— NOs as the 
class property and so on. 

4-2.2 DATA SELECTION PROCEDURES 

Once a subset has been generated with some subset properties 
these subsets may be selected by describing conditions over set 
properties. A simple example is given in the following: 

EOR ORDER :S BEGIN 

EOR EACH ORDER-NO OB ORDER :S BEGIN 

BOR ORDER-NO = 1 0 BEGIN NO-ACTION END 
BOR ORDER-NO NOT = 10 BEGIN 

COUNT ORDER'S AS NO-OB-ITEMS 
BOR EACH OB ORDER :S BEGIN 

MAKESHORT-QTY = ORDERED-QTY - RECEIVED- QT Y 

END 

END 

SUM SHORT-QTY OB ORDER :S AS REQUIRED-QTY 

CREATE INVOICE (NO-OB-ITEMS, REQUIRED-QTY, ORDER-NO) 

END 

The sequence or procedures which constitute the block at the next 
level may operate only on those subsets which are selected by the 
procedure creating the block. Brom one class of subsets only one sub- 
set may be used by procedures. It is implied that procedures will be 
repeated on each subset of the class, separately, disregarding any 
sequence in which these subsets may be present. More complicated selec- 
tion procedures may be described using the data and other classes of 
subsets that may be available far a procedure according to the context. 
The context is further described in Section 4-2.4. 
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4-2.3 DATA 'GENERATION PROCEDURES 

There are various kinds of data generation procedures. Element 
oriented procedures have simple calculations, assignments and condi- 
tional assignments on different properties of elements. One element 
of class is available at a time for these procedures and one element 
may be generated at a time. An element may be a singleton element or 
a subset. Whatever is being treated as an element should be available 
as an element at the level of the procedure, i.e., a procedure has to 
be preceded by relevant subsetting procedures. 

Other than the element oriented procedures there ore set functions 
which operate on a subset. These may not take the subset as an element 
with only aggregate subset properties but may treat the subset as a set 
of elements. Dor built-in set functions like SUM, NUMBER, ALLOCATE, 
COUNT, MIN, MAX, EIRST, LAST, K-TH etc., the set is treated like a 
block box. User-written set functions are very often needed and 
Examples 4-1 describes one such case. In Chapter 3? Example 3-3 also 
describes one such case. Here, the subset is not treated as a black 
box^ but the elements are created, ordered, and processed for aggregation 
at the element level as well as subset level to define such user-written 
set functions. 


* 62148 % 
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EXAMPLE 4-1 

(Running profile of orders, receipts and amount for customers) 


FOR CUST0T1ER-0RDER : S BEGIN 

FOR EACH CUSTOMER-NO OF CUSTOMER-ORDER : S BEGIN 


END 


MAKE DElIVERED-QUANTITYj ORDER-TO-DATE, AMOUNT, ORDER-SERIAL- 

NO = 0 

FOR EACH OF CUSTOMER-ORDER :S, SEQUENCE DATE, ASCENDING BEGIN 
INCREASE ORDER- SERIAI-NO BY 1 

INCREASE ORDER-TO-DATE BY ORDERED-QUANTITY OF OUST CHER- ORDER 
MULTIPLY RECEIVED-QUANTITY OF CUSTOMER-ORDER BY PRICE OF 

CUSTOMER-ORDER GIVING VALUE 

INCREASE AMOUNT BY VALUE 

CREATE CUSTOMER-ORDER-STATUS (ORDER-SERIAL-NO , ORDER-TO-DATE 

AMOUNT; 

DATE, CUSTOMER-NO = ALL CUST CMER-ORDER ) 

END 

MAKE FINAL-AMOUNT = AMOUNT 

SUM RECEIVED-QUANTITY OF CUSTOMER-ORDER AS DELI VERED-QUANTI T Y 
CREATE CUSTO M ER- BILL (AMOUNT, DELIVERED-QUANTITY ; CUSTOMER HO 

= CUSTCMER-NO OF CUSTOMER-ORDER) 


END 


In the example given above, AMOUNT is 
an aggregate property for a subset of all the customer orders for one 
customer which is created by a user ■written procedure. ORDER— TO— DATE 
for running order status is an element property ■which is created by a 
user written set function (i.e., agreegating a property of earlier 
elements in the set). 

In general, a set property at the higher level is always available 
for use alongwith the element properties at the lower level because the 
element belonggto the set. Therefore, what is a subset for a higher 
level is a set for a lower level description. If a set property is 
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updated at the elenent processing level, then at set level it implies 
a generation of a new property. 

4-2.4 DATA NAMING AMD BLOCK STRUCTURE 

Data naming, which is based on a meaning for the name (in accor- 
dance with the context), makes use of the block structure. To begin 
with at is assumed that there is a database containing all the rele- 
vant data sets and their versions. The sets which are being consi- 
dered for the data transformation, are selected. A particular version 
of these sets nay also be selected. Dor example - 

POE ORDER ;S, OUST (MER :S, TRANSACTIONS 

An s with a shows that a number of elements constitute the 
set. This set is available for processing as one subset containing 
the whole set with only one set property, (or the subset property) 
the property being its name. Therefore, at this level it is selected 
by explicitly giving the name. The very first procedure will naturally 

be a subsetting, because it is not attributed any properties at this 

/ 

level which are identifiable. At level one any subsetting procedure 
can take one set as input and a number of subsets or classes can be 
created as output. The number of classes generated may be only one or 
more. Suppose a function subsets one set into three, being that of 
ORDER :S. The meaning of ORDER :S will be altered as follows - 
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FOR ORDER :S, CUSTOMER :S BEGIN 

EOR EACH ORDER-NO of ORDER :S BEGIN 

FOR EACH CUSTOMER-TYPE OE CUSTOMER :S BEGUN 
Comment: meaning at this level 

CUSTOMER : A set of customers with a set property 
customer-type, identifiable by type 
ORDER : A set of orders with a set property 
order-No., identifiable by number., 

Any predicate or description at this level will be 
true for all such sets individually. 

Procedures at the next level will be repeated for all such sets. 
This gives rise to a control structure for implied repetition for 
different sets. It may be observed that like we have PERFORM, DO, 
IF-THEN-ELSE, DO- WHILE, REPEAT and CASE etc., as control structures in 
programming languages, for controlling procedures, data transformation 
languages need data oriented control structures for two reasons - 

1 . Commonly used structures for ea se of description ; 

2. Basic structures, to give the power of control. 

Example 4-2 shows - transformations involving a number of data sets 
and Example 4-3 shows a bills-of -material description to illustrate the 
update needs and capabilities. Normally the repetitions are due to date 
cardinality, but in Example 4-3 they are due to data-values. 


Examples 4-2 and 4-3 are as follows: 


i 
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EXAMPLE 4-2 

POR TRANSACTIGNsS, MASTER ;S, ERROR-MASTER :S BEGIN 
POll EACH ORDER-NO OP TRANSACT!' '1 T ,:S BEGIN 
""m MASTER (ORDER-NO = ORDER-NO OP TRANSACTION) BEGIN 
POR MASTER PRESENT BEGIN 

ADD QUANTITY OP EANSACTIOIT TO QUANTITY OP ULSTER 

GIVING NEYT-QUANTITY 

UPDATE MASTER (QUANTITY = NEV-QUANTITY) END 

POR CODE OP TRANSACTION NOT = CODE OP PIASTER BEGIN 

POR ERROR-MASTER (ORDER-NO = ORDER-NO of MASTER ) BEGIN 
UPDATE MASTER (REASON = REASON OP ERROR-MASTER) END 

over 


(One transaction per order-no is an integrity 
constraints, here) 


EXAMPLE 4-3 


POR PART : S BEGIN 

Tor part-no op part = 137 begin 

CREATE SUB-PART (= ALL OP PART) END 
OVER 

POR SUB-PART sS, PART:S, SU3-P ART-NO :S BEGIN 
BOR EACH OP SUB-PiiRT BEGIN 

POR STATUS OP SUB-PART = 'ELEMENTARY 11 BEGIN 
CREATE BASIC-PART (= ALL OP SUB-PARTTTnd 
POR STATUS OP SUB-PART = "ASSEMBLY" BEGIN 

POR SUB-PART-NO (PIIIENT-P ART-NO = PART-NO OP SUB-PART) BEGIN 
POR EACH SUB-PART-NO BEGIN 

POR PART (PART-NO = PAllENT-PART-NO OP SUB-PART-NO) BEGIN 
ADD SUB-PART (= ALL OP PART) 

END 

OVER 


To show the compactness of description, sone examples of 
data base queries are being taken in the following. 

Query 3.11, [COD 73 ] 

Por each project, obtain as a triple, the project nunber, 
project name and supplier location, for all suppliers #10 supply 


that project. 
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RnNGE PROJECT J 
RANGE SUPPLIER S 

RANGE SUPPLY Z SOME , , 

GBP w( J.J/ff, J.NAME, S.L0C):(j.J # = Z.J/X_y(z.S/ = S.S^O 
EOR PROJECT :S, SUPPLIER :S, SUPPLY :S BEGUN 
POR EACH PROJECT BEGIN 

EOR SUPPLY (j / = J / OE PROJECT) BEGIN 
EOR EACH SUPPLY BEGIN 

EOR S/ OE SUPPLIER = S / OE SUPPLY BEGIN 

CREATE W(j/, NAME = ALL OE PROJECT; LOC ' 
LOC SUPPLIER END 

OVER 


Problem 

Query 3.10 [ COD 71 1 

Give nones and locations of all suppliers, each of whom supplies all 


projects. 


RANGE SUPPLIER S 
RANGE PROJECT J ALL 
RANGE SUPPLY Z SOME 
GET W(S.NAME, S.LOC) : (s.S/= Z.S/ 
EOR PROJECT tS, SUPPLIER'.S, SUPPLY'.S 
COUNT PROJECT :S AS NO-OP-PROJECTS 



Z.J #= J.J / ) 


POR EACH OE SUPPLIER :S BEGIN 

EOR SUPPLY (S^ = SJOF SUPPLIER) BEGIN 


COUNT SUPPLY :S AS NO-SUPPLIED 

EOR NO-SUPPLIED = NO-OE-PROJECTS BEGIN 

CREALE w(NAME, LOC = ALL OE SUPPLIER) END 


OVER 


It can be easily shown that operations of union, iter section, 
difference, projection and restriction, as defined in the relational 
algebra can be easily described using this approach. 
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4-5. 0 OI'TCEPT OP UP DATES IN DATA PROCESSING- 

In a general sense a data processing system constantly updates and 
processes data. Updating is a procedural concept. In an attempt to 
iurJse system descriptions more declarative and less procedural orientation 
of the language should be such that update is used as little as possible. 
Iho situations under which an update is used, can be visualised as 
follows : 

1 . Elementary data item updates 

2. Entity set updates 

3. Property updates for entities 

4. Data, set updates 

Ihe essential typo of update is that of change in the value of the 
properties of a real life entity like customer or a commodity, about 
which the information is kept. Other kinds of updates found in data 
transformations are due to time cycles, data cardinality or cycles of 
processing. In general, on update cycle may be present in a data 
transf ozmation description as given in the figure below. 



PROCESS ECR UPDATING A 
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fach a description does not make clear why the process has 
been described as an update. It just describes that PI, P2 and P3 
arc three processes operating on A, 3 and C and they together fora a 
cycle. In an attempt to bring out the need or the reason for update, 
so that it can be utilised for farther analysis and design, different 
constructs are used for different kinds of updates. 

momentary data item updates, like QUANTITY QUANTITY + AbSEHEHEITT 
are used in data, transformation descriptions. These are basically 
required to construct n-ary operations (an operation involving n 
data items) using binary arithmetic operator. Por example, BILL 
TOTAL = ORDER 1 + ORDER 2 uses a bin, -ry addition operators. Eor seven 
orders, .a ready made n-ary operator SUM can be used SUM ORDER :S AS 
BILL-TOTAL. We could also have BILL-TOTAL = ORDER-QUANTITY * RATE- 
OE-OEDER. In this case a BILL-TOTAL for seven ORDERS will be obtain- 
ed by updating it for every order, su.ch as, BILL— TOTAL BILL— TOTAL + 

OBDER-QUA NTI T Y * RATE-OE-ORDER. Such updates are described by using 
constructs like ADD AMBHDOMEHT TO QUANTITY, INCREASE QUANTITY BY 
AMENDMENT etc. Some n-ary c instructs like SUM, COUNT, NUMBER etc., 
are also defined, to maintain the ease of use. 

Entity set updates, for example, updated customer set after 
deleting selected customers, are handled by ADD and DELETE. This 
avoids update at a description level and makes It, a purely data 
processing level function. Data set updates for removing obsolete 
data from data sets and adding new data to data sets (for example keep- 
ing data about weekly orders) are also made implied data pro- 


cessing functions. 
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Updates for properties of entities and addition and deletion 
of entities have t: be given by the user. Data processing oriented 
updates are not a part of tho description. In this way, descriptions 
become less procedural and user description remains at a. system level. 
Wiis helps in understanding the updates and their needs. 

4-4. TIME AS A SYSTEM CONCEPT 

Hie data processing systems being considered here are botched 
or clocked systems and not real tine systems. In such systems, sets 
of data are collected over preconceived time intervals. Functionally 
similar data, occuring at different points of time, may be identified 
by the associating o. dimension of time with data. Time is required 
as an integral system concept for the following reasons: 

1. ill systems have, as a natural necessity, functions linked 
with some or Hie other time aspect, Any description of the system 
cannot avoid referring to time. 

2. Time may be defined as data type in the system because it 
has a very standard usage and a very complicated data type having 
lot of sub-types otc*, and complicated naming conventions. If the 

user has to describe the data type in the course of the description then 
a lot of information about the structure of the system gets disintegrated 
and remains no more available for the purposes of analysis and design. 

For ex, ample, suppose there are ORDERS for each day of the week. 

There is a data item DAY-OF-ORDER. A data transformation description 
may compare DAY-OF-ORDER with the DATE-OF-RUE giving a detailed matching 
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procedure, extracting the MY from the DATS and then comparing the • 
two data, items. If a facility is given for directly using the DAY 
of a DATE or for declaring DAY- OP-ORDER as a special data item 

which identifies the we eld. y ORDER'S with the respective days then 
this information can he used to analyse the data and structure it. 

3- The storage of data in the system depends on its life time 
and the times at which it is required. Por example, tomorrow's in- 
voices may h ve to be printed today. In other words, data processing 
has to be synchronised with real tine. 

4. Data processing and the real environment synchronises by 
using time as a data item. lor example , orders of the month of 
March are identified by the date of order. 

As n system concept, conversion from a tine data item to real 
time identification and vice-versa, are needed. A case study given 
in Chapter 6 has an example where an amendment document has two 
time identifications. Amendment entering on Monday, as the amend- 
ment for Tuesday. In such cases at a time, one of the time items 
appearsas a data item .and the other as a time tag. This is achieved 
by two features of the language - 

1 . PERIOD nay be used to declare the time tag 
2. Data item nay be equated to a time-item. 

Time as a system concept, also needs to allow additional tine 
intervals, periods and sub-intervals which nay be very specific 
to a system. Eor example four shifts a day is a specific interval. 
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Saturday to Friday week is a specific interval whereas Monday to 
Sunday week is a general interval. 

Time as a system concept, should allow making a reference to 
any point in time. For example, two days before today. For doing 
this, the current real time status should be available for reference. 
For example, one may like to check if the week of the order is current 
week. 


The user is clearly able to perceive timings of various operations 
in the system and the system designer is able to generate data items 
related to time. 


S 


main cydLe -1.™ , of the °y cle for ®y stea . pr0 ~ 

sub -cycle , N t/, jw \*j j* U -part of the cycle cessing 

Iron the view point of computerised processing, a time interval 
nay be divided into three p r arts*. Beginning of the interval, when 
the system processing can be dene* Middle of the interval during 
which things belonging to that interval, nay happen in the envir onment * 


End of the interval during which system processing can be completed* 


For example, for the day, the order* s of the day have to be processed* 
It implies processing at the end of the day* normally end-of-the- 
interval processing nay be ta.ken as usual and the beginning— of- th e-day 
processing may be considered only if there is a special declaration* 

If the distribution of the processing is specifically complicated 


over different tine intervals and sub-intervals of time then the 
block structure of description can be readily exploited* 
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4-5- DESCRIPTIONS FOB. INPUT DOCUMENTS 

Essential features required for the description of documents 
or the inputs to the systen are similar to those for report descrip- 
tions. The main difference is that reports are more structured than 
input documents. The input from the environment is prepared by people, 
raid hence the data is more raw, or less processed and therefore it 
is in simple forms. It nay have more codes built into the data items 
to avoid data entry errors. Input forms may have unfilled portions, 
which are allowed to be optional and in that case they should not be 
used to generate data item strings. This occurs becauses forms have 
a rigid structure and do not adjust themselves like reports, depend- 
ing on the presence of data . This needs special f enture in being able 

to ignore unfilled portions. 

Input media control procedures like skipping to a new form and 
input media condition sensing like creating a code from the line number 
on the form, etc., are similar to corresponding report description 
features. VALUE olause for data items nay be used to cb scribe data 
integrity constraints on individual data items. In some cases the input 
medium nay be linked to a message control system. Then input may have 
more report-like structure according to the presence or the absence 
of data. 

The case study given in the Chapter 6 illustrates these features. 
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4-6. SYNTAX OP THE LANGUAGE 

The syntax of the language is given below. Report description 
part of the language, which is given in Chapter III is being ooitted 
here. Syntax for input descriptions is sane as that for report 
descriptions and is not being repeated. 

< APPLI CATI ON-SYSTEM> : := <DESCRIPTION> END-OE-DESCRIPTION 
<DESCRIPTI 0N> ::= < SINGLE-MODULE > j ASCRIPTION > <SINGLE-MODULE > 
<SINCLE-MODULE > : := < THE -MODULE > |<OTHER-MODULE> 

<OTHER-MODULE> : :=< NECESSARY-CONDITION > <AFY-MODULI> 

<ANY-MODULE> : := <REPORT-MODULE> | < DOCUMENT-MODULE > | 

< DATA- TRAN SEO IffiHATI ON-MODULE > 

<REPORT-MODULE > : := REPORT •'REPORT -DESCRIPTION > 
<DOCUMENT-MODULE > : := <DOCUMENT-DESCRIPTION > 

<NECESSARY-C 0NHTI ON > : := < EMPTY > | EOT. < C CNDITI ON-DETAIL > 

< CONDITION-DETAIL> : := EACH < REL EVANT-DATA-ITEM> 

I'HEN < SINGLE-ITEM-C ONDITIOil > 

< RELEVANT— DATA— ITEM> : := <DATA-ITEM >| <SYSTEM-DATA-ITEM> 

< SYSTEM-DATA-I TEM> : :=< TIME-CYCLE 5, | <TIME-INSTANT > 

BEGINNING OE< TIME-CYCLE > 

< SINGLE-ITEM-CONDITION> : := < DATA -ITEM>< RELATION > < DATA'_ITEM> 

< DOCUMENT-DESCRIPTIONS : := DOCUMMT < DOCUIffiNT-NAME >TO DATA SET 

< DATA-SET-NAffi^DOCUMENT-DETAIL > OVER 


COMMENT s The document description is identical to report 
description given in Chapter III other than the 
following additions. 
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< RANGE-OP-VALUE’> : s= < RANGE-OP- VALUES X RANGE-OP- VALUES ^ < LITERAL > 

^LITERAL TO LITERAL > 

SIMPLE-PROCEDURE : := UNPILLED, IGNORE^ INTEGRITY-CONSTRAINT > 

< VALUE-CLAUSE : := VALUE X^EGE-OP-VALUESj) 
cINTEGRITY-CONSTRAINT > s := ALL REQUIRED 


<COPY- STATEMENT > : := SAME-AS < MODULE-NAME > | 

SAME-AS <J.IODUL E-NAME > USING 

X < set-op-pakaiieters>2 

< SET-OP-PARAMETERS> : := <PARAMETERS><SET-OP-PARAMETERS> | 

<PARAMETERS> 

<PARAMETER> : := < SET-OP-WOSDS> FOR <SET-OP- WORDS > 
<SET-OP- WORDS > ::= <WORD> 1 < WOED> < SET-OP-WORDS > 

<DATA-TRANSPORMTION-MODUEE > : := DATA-DESCRIPTION 

< MODULE-NAME > 

< DATA-DESCRIPTION > 

OVER 


< MODULE-NAME > : :=< VARI ABL E-NAME ^ ML <EMPTY> 

< DATA-DESCRIPTION> : := <DATA-DESCRIPHOH>< DATA-DE SCRIP HON> | 

PQR < DATA-CONDITION > BEGIN 
<DATA-DE SCRPTION > END | < DATA-SIATEMENT > 

< DATA-C CEDITION> ; := < DATA- SELECTI ON > | <DATA-SUBSETTING> 

< DATA-STATEMEND> : := < ENTITY- STATEMENT > | 

< SET-PROPERTY-GENERATION > 

< DATA-ELEMENT-GENERATI ON > 

< OTHER-STATEMENTS > 

< ENTI TY-STATEMB NT > : :=< CREATE- STATEt.CE NT> | 

< ENTITY-SET-UPDATE > | 

< ENTITY-PROPERTY-UPDATE > 

< CREATE-STATEMENT > : := CREATE < SET-NAME> X^ET-DOMAINS^ 

< ENTITY-SET-UPDATE > ; ;= ADD< SET-NAME>X< SET_:D0IIAIITS> -1 I 

DELETE< SET-NAME> <SET-DOMAINS >) 

< ENTITY-PROPERTY-UPDATE > : := UPDATE < SET-NAME> ‘SET-DOMAINS ^ 
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< DATA-ELEIIENT-GENERATION > : := HAKE <VAPIABLE-NAI'tE> = < AN^-DATA > | 

INCREASE < VArjA3LE-UAIffi> BY <ANY-DATA> | 
<MULTIPLY-CLAUSE ><{: OTHER-CALCULATION > 

< ANY-DATA > : := <DATA-ITEM > | < LIBERAL > | < TIME-IN START > 

< SET-PROPERTY-GENERATI Oil > : := SUM <DATA-ITEM >AS <VARIABLE-HAME?> | 

COUNT <DATA-SET >AS < VARIABLE-NAME> | 

NUMBER OF <DATA-ITEMx SEQUENCE > AS 

<variablianame > 

< SET-DOMAINS > : := < VARIABLE-NAME-STRING >= ALL OP < SET-NAME > | 

ALL OP < SET-NAME > | 

< VARIABLE-NAME* = <DATA-ITEM > | 

< YARIABLE-NAME-STRINO j ( 

< SET-DOMAINS > , <SET-DOMAINS > 

<SEQUENCE > : := ASCENDING- | DESCENDING- 

<DATA-ITEM> : :=< VARIABLE-NAME > | <VARIABLE-NAME> OP <DATA-SET > 1 

<DATA-ISEM > REDESCRIBED BEGIN < DATA-ITEM-STRING > END | 
POSITION < INTEGER >TO < INTEGER > OP <DATA-ITEM > 

< SET-NAME > : := <DATA-SET-NAME> < LOCAL-RENAME > I < VARIABLE > : _S fc VARIABLE > 
<DATA-SET-NAME > : := < DATA-SET >| < DATA-SET > OP_ ’TIME INSTANT > 

<YIJR ABLE — NAME — STRING> : := < VARIABLE-NAME > |< VARIABLE-NAME xvARIAELE-NAIffi- 

STHINGb- 

<DATA-ITEM-STRING>: := < VARIABLE-NAME-STRING>| <VARIABLE-NAME> REPEATED 

< INTEGER > TIMES 

< DATA- SELE CTION > : := < VALUE- SELECTION >!< SET-STRING > 

<SET-C BECKING > 

< SET-C BBC KING > : := < SET-NAME > <CHECK > 

< CHECK > : := PRESENT I ABSENT I TYPE < SET-NAME > 

< VALUE-SELECTION DATA-ITHE>r RELATION* GIVEN-ITEM > 

< GIVEN-ITEM > : := <DATA-ITEM> | <LITERAL > | < TIME-DATA-ITEM > 

< SET-STRING *:= <SET-NAME> j < SET-NAME > < SET-STRING > 

< SEQUENCING > : := SEQUENCE ON < SIMELE-DI-STRING > < SEQUENCE > 

< DATA-SUBSEITING > : := <SUBSETTING > i <SEQUENCING> 

< SUBSETTING >: := <T\TO-SET-SELECTION > | cINTEGER > TIMES 

EACH <SIMPLE-DI-STRING U EACH < TIME-PERIOD > 

< SELECTED-DI-STRING > | - 

< TIME-TAG> 0£< DATA-SET > 

< DATA-SET> TYPE <DATA-SET > 
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< OTO-SET-SELECTION > : := < SET-NAME>_[ ^SET-DOMAINS >]_ 

<SELI]DTED-DI-STRING> : := <DI-SELB3TION> | < DI-SELECTION> cCONNECTOR > 

<SELEC TED-DI - STRING > 

<COWECTOR> , |AND |OE 

< DI-SEL BO TI ON> : := <SIMPLE-DI-SELECTION> |< RAITGE-DI-SELECTION > 

< SIMPLE-DI-SELEGTI OF >: := <DATA-ITEM>= <ANY-ITEM > 

< RANGE-DI-SELECTION > : := < DATA-ITEM >= <VALUE-STRING > 

< VALUE-STRING > : := <ANY-ITEM>| < VALUE-STRING^ <VALUE-STRING > 

< ANT-ITEM < AN I ITEM > 

< GLOBAL-RENAME > ::= <DATA-SET-NAME > DEFINED AS <DATA-3ET-NAUE > 

< OTHER-STATEMENTS > : := < COPY-STATEMENT >| < GLOBAL-RENAME- > | 

<L OCAL-RENAME- > | < VERSION-TIME > 

< IOC AX-RENAME > : := < DATA- SET-NAME > CALLED < DATA- SET-NAME > 

< VERSION-TIME > : := PERIOD <E QEMATTED-TIME-INSTANT > IS_ < GIVEN-ITEM > 

OF <SET-NAME > 

< TIME-FORMAT > : := < STJB-CYCLE> OE <SUPER-CYCLE >BY<NUM3ER > | 

< CYCLE> m ^NUMBER >|< CYCLE > BY -NAME > | ' 

< TIME-EO IMAT > , < TIME-FORMAT > 

< EOBI/iTTED-TIME-INSTANT> : := < TIME-INSTANT > _£<TIME-FORMAT ^ 

< CYCLE >::= DAY | WEEK | YEAR | MONTH | QUARTER | HOUR < TJSER-GIVEN-CYCLE> 
<USER-GIVEN-CYCIE >: :=< SUPER-CYCLE >| < SUB-OYCLE > 

< SUPER-CYCLE >::= < SUPER-CYCIE-DEEINITION > 

< SUB-CYCLE > : s= PERIOD < INTEGER > < VARIABLE-NAME > IN < VARIABLE-NAI.CE > 

< TIME-DA TA-ITEM > : := < TIME-INSTANT ^ ^ORMATTED-TIME-INSTANT > 

<TIME-INSTANI . > : := TODAY | TOMORROW f YESTERDAY | 

< USER-0 ONSTRUCTED-INSTANTS >| 

< SYSTEM-CONSTRUCTED-INSTANTS > | 

< USER-DEEINED-INSTANT > 

< USER-CONSTRUG TED-INSTANT S’- : := < CYCIE-OOUNT > < CYCLE > 

< TIME— REL ATI ON ><TIMB-INSTANT > 

< USER-DEEINED-INSTANT > : := PERIOD < VARIABLE-NAME >EROM <TIME-INSTANT > TO 

< CYCLE-COUNT > : :=< EMPTY >|< INTEGER > <DIME-IN STANT > 


> . 

# • 


< TIME-REL ATI ON 


BEFORE I AFTER 
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< SYSTEM-CD NSTRUCTED-INSTANTS > : := CURRENT < CYCLE > | 

LAST< CYCLE > 1 
NEXT CYCLE > 

< SUPER-CYCLE-DEPINITION > : := < OVER-LAPPED-CYCLE “ DEFINITIONS | 

< EVEN-C ICLE-DEFINITION > | 

< III EVEN-CYCLE DEFINITION > 

< 0V1EL APPED-C Y3L E-DEEINITION > : := PERIOD <USER-CYCLE > 

IS FROM <TII, IE-INSTANT > TO <TIME-IITSTANT> 

< EVEN-C YCL E-DEPINI TI 0N> : := < EVEN-CYCLE > 

< EVEN-C YCLE> : := PERI0D< USER-CYCLE > IS MADE OE < INTEGER x CYCLE > 

< UNEVEN-C YCLE-DEEINE TION > : := < UNEVEN-CYCLE > I < UNEVEN-CYCLE> 

< UNEVEN-CYCLE-DEFINITION > 

< UNEVEN-CYCLE > : := PERIOD < USER-SYCLE> “INTEGER 

IS MADE OF cINTEGER > < CYCLE > 

< USEE-CYCLE > : := <VARIABLE-NAME > 

< EVEN-C YCL E-NAME> : := < NAME-CLAUSE >]= NAME-CLAUSE XEVEN-CYCLE-NAI1E > 

< NAME-CL AU SE > : := NAME 0F< CYCLE >1< INTEGER X IS cLITSRAL > 

4-7. CONCLUSION 

The system description approach taken in the language described 
in this chapter preserves nost of the structure of user's system in 
a usable or understandable fora. This is achieved firstly by using 
tine as a system concept. By eliminating explicit use of loop- 
structure by providing features for data cardinality and different 
kinds of update requirements. 

To give completeness to the formal system description, inputs 
can also be described using the DOCUMENT feature. Timing needs of the 
system and its relation with the environment, can be integrated with 
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the system description. A limitation of this approach is that it 
does not aim at getting the informational view of the system or 
understanding the system hut it only aims as getting a precise data 
model of the system and depends on the user to he ahLe to state his 
information requirements in terns of data requirements. In this way, 
instead of making the description fully declarative, it remains 
procedural to the extent that the 'know how 1 of data associations for 
the required information has to he given by the user. 

At the detail level, the different kinds of data mappings any he 
obtained by the mechanisms of subsetting, data selection and data 
generation. Built-in mechanism for 1 -*■ M subsetting, 1 M data 
selection and M + 1 (COUNT, SUM), 1 1 (REPORT data items), 1 M 

(NUMBER) data generation have been provided. Here 1 M etc use M ' 
in a general sense of either a set or an element . However* M -> H 
napping on all the three mechanism, in a user described, explicit 
nomer is facilitated by using the block structure and the relented 
subset naming mechanism which is implied by the structure# A limita- 
tion at this level, is that the subsetting procedures can put one 
clement of the set, only in one of the subsets at a time# If multiple 
copies of an element have to be put in different subsets then this 
can be indirectly done by selecting more copies at the beginning of 
a procedure. However, this limitation also limits the user from 
making unreasonable descriptions while being unaware of it. 
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In the end, it can be said that the approach leads to a simple 
description, concisely, so that the description com be used for 
computer-aided analysis and design. It is structured to maintain 
the structural properties of the described system at a usable level. 
An information system links itself with reality and the associated 
organisations or the firm by inputs, outputs and the associated 
timings. Ihese facilities are provided in this approach for complete 


ness of description. 



CHAPTER 5 


SYSTEMS ANALYSIS 

In the last two chapters of the thesis a system description 
language j SDL, has been developed which can be used to fully des- 
cribe &n information processing system required by the user. The 
inputs, outputs and the timing descriptions formulate the inter- 
action of the information processing system with its environment 
or the organisation which will use the system. The data transfor- 
mation descriptions fomulate how the system should hehave, or 
should work out the data associations. 

Such a description can be used as a documentation aid to the 
systems analyst. It will, however, be of much greater impact if 
it can be used as a design aid. In this chapter we will discuss 
how such a description can be used for computer aided system analysis 
and design. Systems analysis, today, is done manually by a systems 
analyst. In the following section, we will discuss how simple ana- 
lysis about the availability of the required data, can be done. Then 
we will proceed to discuss why such an analysis is much less than 
wliat a systems analyst does. In Sections 5-1 to 5-5 we will discuss 
some new methods of systems analysis which exploit the structure 
of SDL, for interactively extracting inf ornation relevant to analysis 
and design. 
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let us start with a snail example of a system which keeps master 
inf ormation about the costs of products* This system receives invoices 
and checks certain items like discount and product v al ue * It is an 
invoice audit* It prints out a report for those invoices where some 
discrepancies are found* The description of reports^ inputs and data 
transformations are given in SDL in the following* (The format dia- 
grams of input forms and reports are given purely to assist the reader.) 


PRODUCT POEM 


(lO Lines per form) 


PRODUCT 

CODE 

STA HOARD 
LABOUR 
PRICE 

STANDARD 

MATERIAL 

PRICE 

MAXIMUM 

DISCOUNT 

PERCENT 

DESCRIP- 

TION 

SELLING 

PRICE 

1345 

97.34 

13.56 

1 2 

TXPE-1 

153.67 
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FOR EACH DAY 

DOCUMENT PRODUCT-FORM TO DATA SET COST-MAS TER :S 
FOR EACH 10 C OST-MASTER s S BEGIN 
NEW-FORM AFTER 5 LIKES 
FOR EACH COST-MASTER BEGIN 

PRODUCT-CODE, STANDARD-LABOUR-PRICE, STAHDARD-MATERIAL-PRICE 
SELLING-PRICE IE SCRIP ETON MAX-DISC CONT-PERCENT END 
FORMAT PRODUCT-CODE FROM 4 SIZE 4 STA NDARD-LABOUR-PRICE 
FRCM 11 PICTURE 99,99 STAKDARD-MATERIAL-PRICE FROM 19 PICTURE 
99.99 MAXIMUM-DISCOUNT-PERCENT FROM 28 NUMBER SIZE 2 DESCRIPTION 
FROM 32 SIZE 10 SELLING-PRICE FROM 45 PICTURE 999.99 
OYER 


INVOICE FORM 

PRODUCT CODE 1345 INVOICE-NUMBER 1001 YEAR XX WEEK-NO XX , 

| ! 

| CLASS OF TRADE XXX CUSTOMER NOS 1056 AREA LC QUANTITY 50 

i 

PRODUCT VALUE XXXX 

DISCOUNT VALUE XXXX SIGNATURE STAMP ! 


FOR EACH DAY 

DOCUMENT INVOICE-FORM TO DATA SET INVOICE :S 
FOR EACH INVOICE BEGIN 

NEW-FORM AFTER 1 LINE, PRODUCT-CODE, INVOICE-NUMBER, WEEK-NO 
YEAR-NO NEW-LINE CLASS-OF-TRADE CUSTOMER-NO, AREA 
QUANTITY NEW LINE PRODUCT VALUE 
NEW-LINE DISCOUNT-VALUE END 

FORMAT PRODUCT-CODE FROM 15 NUMBER 4 INVOICE-NUMBER FROM 34 
NUMBER 4 YEAR-NO FROM 44 SIZE 2 WEEK-NO FROM 52 SIZE 2 
PRODUCT-VALUE EACH 15 SIZE 4 DISCOUNT VALUE FROM 15 SIZE 4 
CLASS OF TRADE FROM 15 SIZE 4 AREA FROM 44 SIZE 2 
QUANTITY FROM 5 2 NUMBER 2 CUSTOMER-NO FROM 34 SIZE 4 
OVER 
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REPORT OR INVOICE EDITING PAGE 1 


PRODUCT 

INVOICE 

CALCULATED 

PRODUCT 

maximum 

DISC CUNT 

C GHENT 

CODE 

NO 

VALUE 

VALUE 

DISCOUNT 

VALUE 


0513 

10 

53.5 

53.0 



COIflMENT-1 

0600 

1 



10 

12 

C0IL1EHT-2 

0713 

3 

60.0 

65.0 

9 

15 

o o 
o o 

PI 

gj S 

ff 

JO 

0613 

6 

23.5 

23.0 



CGE1ENI-1 

♦ • • 9 

1 

& • 

• * * » 

.... 

P ♦ 


- — 

* • * » 

''-s, _ 

* • 

• * * * 

• * • • 
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EOR EACH DAY REPORT INVOICE-EDIT 
PROM DATA SET INVOICE-AUDIT :S 

BLANK 1 2, "REPORT Oil INVOICE EDITING, " PAGE-NUMBER 
NEW-LINE, HEADING-LINE-1 , NEV-LINE, HEADING-LIHE-2 
EOR EACH OP THE INVOICE-AUDIT BEGIN 

EOR DI SC CUNT- ABOVE-MAX = 1 OR VALUE-DISCREPANCY-COUITT = 1 BEGIN 
NEW-LINE, PRODUCT-CODE, INVOICE-NO 
EOR VALUE-DISCREPANCY-COUNT = 1 BEGIN 
CALCULATED-VALUE, PRODUCT- VALUE MID 
EOR DISCOUNT-ABOVE-MAX = 1 BEGIN 

MAXIMOM-DI SC OUNT , LI SC CENT- VALUE END 
C CWENT-1 

EOR COMMENT- 1 = BLANK BEGIN COMMENT- 2, MD 
EOR COMMENT-1 BLANK AND COMMENT-2 / BLANK BEGIN 
NEW LINE, COMMEHT-2 ML ' ~ 

EOR NEW-PAGE BEGIN PAGE-NUMBER END 
FORMAT HEADING-LINE-1 EROM 1 VALUE "PRODU"- 
-"CT INVOICE CALCULATED PRODUCT MAXIMUM DISCOUNT COMMENT" 

HEADING- 2 EROM 2 VALUE "CODE NO."- 

VALUE VALUE DISCOUNT VALUE" 

PRODUCT-CODE EROM 2 SIZE 4 INVOICE-NO EROM 12 SIZE 2 

CALCULATED-' VALUE EROM 24 PICTURE 99.9 PRODUCT-VALUE EROM 36 PICTURE 99.9 
MAXIMUM-DISCOUNT EROM 45 SIZE 2 DISCOUNT-VALUE EROM 55 SIZE 2 
COMMENT EROM 60 SIZE 10 
OVER 
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FOR EACH DAY 
DATA-DESCRIPTI 037 EDITING 
FOR INVOICE :S COST-MASTER :S BEGIN 
EOR EACH INVOICE BEGIN 

FOR YEAR-NO = CURRENT YEAR BEGIN 

FOR COST-MASTER (PRODUC T-C ODE = PRODUCT-CODE OF INVOICE) BEGE N 
CAIiCULaTED-VALUE = SELLING-PRICE * QUANTITY 
FOR CALCULATED-VALUE £ PRODUCT-VALUE BEGIN 
MAKE VALUE-DISCREPANCY = U A " 

MAKE C QMMENT-1 = "VALUE-DISCREPANCY" END 
MAX-DISCOUNT-VALUE = CALCULATED-VALUE * MAX-DISCOUNT-PERCENT 
FOR MAX-DISCOUNT- VALUE <DISCOUNT-VALUE BEGIN 
MAKE DISCOUNT-ABOVE-MAX = "1 " 

MAKE COMMENT-2 = 'DISCOUNT ABOVE MAX" END 
CREATE INVOICE-AUDIT (COMMENT-1 , COMMENT- 2, CALCULATED-VALUE, 
PRODUCT-VALUE MAXIMUM-DISCOUNT, DISCOUNT- VALUE 
PRODUCT-CODE INVOICE-NUMBER QUANTITY DISCOUNT-ABOVE-MAX 
VALUE-DISCREPANCY-COUNT ) 

OVER 


Two inputs, namely PRODUCT FORM and INVOICE FORM, one report 
INVOICE AUDIT and EDITING data transformation, are used to describe 
the system. To analyse the system data needs for the reports and data 
availability from she input documents mil be derived. Also, some 
data i ay not be available directly from the documents but from data 
transformations. Data transformation may need some data to carry out 
the transformation, and that should also be available in the system. 

In the following description the data will be represented as relations, 
for each of reference. Every data item will be given a composite 
name as ' data-iten of sot-name 1 . Every relation (as used here) will 
have 4 constituents : a relation name, an associated set name, a set 
of key data items, a set of attribute data-items. 



75 


A procedure to derive the data needs from, reports has already 
been given in Chapter III. Similar procedure can be written for 
getting data availability from the documents. A similar procedure 
is given below to get the data needs and data availability for the 
data transformations. 

1 . Identify the data items with only one of the data sets 
used in the data transformation module, if there are raore than one data 
sets • If two or more data sets have same data item name then the user 
should be asked to clear the error. In the above example, in the 
EDITING module, QUANTITY will be associated with INVOICE and SELLING 
PRICE with COST-MASTER. If there was a SELLING-PRICE in the invoice 
also then cither the description should be CALCULATED-VALUE = QUANTITY 
* SELLING-PRICE OP COST-MASTER or the user will have to clear the doubt. 
Por left hand side items of MAKE and the calculations, a set name should 
bo generated and associated. 

2. Associate a level-number with every data item, by starting 
with level-No. 1 and increasing the level— No. by 1 with every BEGIN and 
decreasing the level-No. by 1 with every END . The dota-items should 

be entered in the sequence in which they are encountered, to maintain 
the block structure of the description. 

3. Por each statement of the type POR EACH data set , introduce 
a special data item as IDENTIPICATION-NO at the proper placo in the 
table, with the proper level No. 
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4. Mark all the data, itens on the left hand side of a calcula.- 
tion, MAKE and CREATE as available type . All those on the right 
hand side are to be narked as ! N' or needed itens. 

5 . Mark all the items in EOR statements, excluding those on the 
right hand sides, as KEYS or 'K' . Others are to be narked as ATTRIBUTES 
or ’ A's. Use RCR statements with equals using two data itens, to list 
the synonyms. 

6. Repeat the following steps for all the attribute type of itens, 
to generate relations. Also repeat for the lowest key of relations 

of the typo l A' or available. 

7. Take the level No. of the data-iten. Reduce the level by one. 
Put all the key itens of the first occurrence of this level as the keys 
in the relation being generated. 

8. Repeat Step 7 till the level-No. becomes zero. 

9. If the attribute is not a generated item, then keys belonging 
to its own set name are to be retained only. 

10. All the relations which ore identical but for the attribute 
data none may be consolidated in one relation by putting the attributes 
together as a set of attributes. 

A list of relations, as worked out by applying the above procedure 
is given below. Codes are introduced for readability, within the 


parantheses . 
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Feed or 
quclibil 

Relation 

Set-name 

Keys Attributes 

(from 

report INVOICE-EDIT ) 



N 

R1 

INVOICE-AUDIT 
(si ) 

IDENTIFI CATION-NO 

(si id) 

DI SC OUNT-ABO VE-MAX 
(SI El ) 

VA1UE-DI SCREPANC Y- 
COJ1TT 

(S1E2) 

PRODUCT-CODE 

(si 15 ) 

INVOICE-NO 
( SI F4 ) 

IT 

R2 

SI 

SI ID, SI El, S1F2 

CALCULATED-VALUE 

(si 15 ) 

PRODUCT-VALUE 

(S1F6) 

IT 

R3 

SI 

SI ID, SI FI, SI F2 

I1AXMUM-DI SC OUITT 
(S1F7 ) 

DISCOUNT- VALUE 
(SI F8 ) 

IT 

R4 

SI 

SI ID, SI FI, SI F2 

COIEJEHT1 

(S1F9) 

N 

R5 

SI 

SI ID, SI FI, SI F2, 
S1F9 

COIffiffiITT-2 
(SI FI 0) 

IT 

R6 

SI 

SI ID, SI FI, SI F2, 
S1F9,S1 FIO 

SI FIO 

(fran document PRODUCT FORM) 



A 

R7 

COST-MASTER 

(S2) 

IDENTIFICATION 

(S2ID) 

PRODUCT-CODE 
(S2F1 ) 


STANDARD-LABOUR- 

PETGE 

(S2F2) 

STAITDARD-MTERIAL- 
YALUE 
(S2F3 ) 

SEEIilHG-PEEGE 
(S2F4) 
DESCRIPTION 
(S2F5 ) 

MAX-DI SC OUNT- 
PERCENT 
(S2E6) 
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Heed or Relation Set Naue 

avail ability 

(front document INVOICE FORM) 


Key s Attributes 


A 


RS INVOICES 

(S3) 


IDENTIFICATION (S3P1 )PRCDUCT~ 
(S3 ID) CODE 

(S3D2) INVOICE- 
NUMBER 

( S3D3 ) YEAR-1TO 
(S3E4) GUSTO! CER- 
NO 

(S3D6) AREA 
(S3E7) QUANTITY 
(S3P8) PRODUCT- 
VALUE 

(S3F9) DISCOUNT- 
VALUE 

(S3S10) UEEK-NO 


(fron data transformation EDITING) 


N 

R9 

S3 

S3 ID 

S3E2,S3E7,S3E1 

I'J 

RIO 

S2 

S2E1 

S2E4 

A 

in i 

NIL 

(S4) 

S3E3,S2E1 
S3 ID 

CALCULATED-VALUE 
(S4FI ) 

N 

HI 2 

S4 

S3E3,S2E1, 
S3 ID 

S4E1 

A 

HI 3 

NIL 

(S3) 

S2E1 ? S3ID 

VALUE-DI SCRE- 
PANCY 

(S5P1 ) 

COIfflIENT-1 

(S5E2) 

A 

R14 

NIL 

(S6) 

S3P3,S2E1, 
S3 ID 

IdAXIMUfl-DI SC OUNT- 
VALUE 
(S6F1 ) 

N 

R15 

S4 

S3E3,S2E1 , 
S3 ID 

S4E1 

N 

El 6 

S2 

S2E1 

MAX-DI SC OUN T- 
PERCENT 


(S2E6) 
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Ifeed or 
avail ability 

Relation 

Set Nolle 

Keys 


Attributes 

N 

R17 

S3 

S3;D, S3P3 


S3P9 

11 

R18 

S6 

S2P1 , S3ID, 
S3P3 


S6P1 

A 

R19 

S7 

S2P1 , S3 ID, 
S3P3 


PI SC OTJl'T f-ABOVE- 
IIAX 

(S7P1 ) 

C0IMB1TT-2 

(S7P2) 

A 

R20 

SI 



QUANTITY 
( SI F1 1 ) 

SI FI ,S1P2,S1F3, 
S1F4,S1F5,S1F6, 
S1F7, SI F8, S1F9, 
SI FI 0 

N 

R21 

S3 

S3P3, S3 ID 


S3F8 

Matching of 

the relations 1 

can be shown 

as follows : 



R1, R2, 

B3, R4, B5, R6 

+• R 20 

R 18 *■ 

R14 


R17,R9 ■ 

*■ R8 


R12 

R8 , R1 1 


R16,R10 

R7 


R15 * 

R11 



Superfluous data: SI P1 1 , S2F5 

The above kind of notching is simple data analysis. There nay be 


loops of data transformation in the definition. Por this, further 
analysis nay be done to identify errors in the definition. The above 
kind of analysis is present in the software systens which do computer- 
aided analysis. However, a systens analyst normally would have done 
the following analysis to find sone more shortcomings of the above 


description 
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1 . This system description can have two interpretations. Product 
forms for all the products nay be required every day or product foias for 
only the new products nay be accepted everyday and may be used alongwith. 
the old product information. If needs to be made clear, as to which of 
these interpreta.tions is correct. User nay assume that it is a well 
known conventional fact. 

2. If a master record is absent then also the invoice should be 
marked for audit. 

3 • If the year is not correct then the invoice should be marked 
for audit. 

4. If invoices are read product— wise, it nay involve less reading 
of information. 

5. If there are two products in the sane product code then some- 
thing should be done, unless it is an integrity constraint for the 
system- 

Phis brings out some of the other aspects of real life system 
analysis. The structure and the level of the language developed in 
tills thesis, has been selected in such a way as to facilitate more 
detailed systems analysis. In the following sections, we will discuss 
how the system descriptions nay be refined, by interacting with the 
user in relation to various aspects of design and analysis, like 
integrity, selection, subsetting and cardinality. 
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5-1 . DATA INTEGRITY AMD SUBSETTING 

At any level of processing only aggregate properties of the 
subsets nay be used for data selection and generation. If the sub- 
set itself is an olenentj then all the element properties may be used 
for such a purpose. 

To explain this by continuing the sene example let the invoice 
audit system be expanded to keep product master information for 
different branches of the same product, using only one product code 
for one product. In this example the situation is very clear and the 
user may account for it. But in many cases omissions are made. In this 
situation the user should either put it as an integrity constraint or a 
necessary requirement from the data that there will be one cost-master 
for one product-code or user should do further data selection to identify 
the product with proper selling price and then use the information. 

The following procedure may be used to identify such situations and 
generating a query for the user. 

1 . Do the following for each data description module for sub- 
setting for each data set used, taking the sets one by one. 

2. For the set, create a list of level-vd.se items, for those items 
which are used in the subsetting operations. If data item is used 

in data selection or generation at a certain level, but it is not 
available in the table at a lower level then the following query should 
be generated: "WILL THERE BE CfflLY ;OHE GOST-MASTER (or the data set used) 
DOR A OTIQUE PRODUCT-CODE (or set of ITEM 1, ITEM 2, ... for all the 
entries in the table for lower levels)?" However, if the subsetting 
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is due to on element level before such use, by a 'POR MACH data-set' clause. 
Ihen. no message is generated. 

3. If the answer to the query, generated in the previous step 

is 'yes' then it becomes an integrity constraint to be checked during 
creation or update of COST-MASTERs. 

4. If the answer is 'no' then a new query "IP THERE ARE MORE THAR 
ONE C 0 SI-MASTERS (or data, set used) HOY* r TO SELECT SELLING-PRICE (or the 
data-iten which generated this query)?" is generated. 

One more problem in the example could be identified, A COST— MASTER 
nay not be present for a PRODUCT-COLE or an invoice may have a wrong 
PRODUCT-COP® • In data processing such checks have to be made. User 
nay not bo aware of this though his organisation may be making a nanuaL 
check for such a problem. This can be analysed in the following way. 

1 . Do the following for every data transformation module and for 
every data set. Identify .all the data subsetting classes which use data 
selection such as COST-MASTER (PRODCT-CODE = PRODUCT-CODE OP INVOICE ) . 

Por these transformations do the following - steps. 

2. Scan further description to find out if the user has checked 
the presence and absence of the selected data set. If it is not so 
then do the following step. 

3. Insert a query just after the statement. "IP THE COST-MASTER 
(data set) POR PRODUCT-CODE = PRODUCT-CODE OP INVOICE (the expression) 

IS ABSENT? CAN IT BE ABSENT? 
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. 4. If the answer is ' Mo T then ask the user to insert an integrity 

chock somewhere, if possible. 

5 • If the answer is 'Yes' to query in Step 3 the user will introduce 
the required data transf ormation(s ), if any. 

5-2. DATA CARDINALITY 

The structure of the language is such that it makes the user aware 

of the sets and elements at any stage. The user is discouraged from 

thinking in terns of embedded and repeating groups. If the cardinality 

of these sets is known at different levels then this could generate 

good design information. For ex anp l e : 

* FOR EACH CUSTOMER-NO OF INVOICE :S BEGIN 

COUNT INVOICE :S AS INVOICES-OF-A-CUSTOMER 
FOR EACH INVOICE BEGIN 

i tFOR COST-MASTER (PRODUCT-C CUE = PRODUCT-CODE OF INVOICE) 

BEGIN 

MAKE AMOUNT-1 = STAIIDARD-LABOUR-PRICE 


etc 

Let there be 10000 invoices, 200 customers and 20 products, approximately 
500 invoices per customer and 10 products ordered per customer. Ree.ding 
of COST-MSTER can be reduced from 10000 to 2000 if data selection is 
done product-wise. Such areas could bo located by the following method. 

1 . Select data description modules with two or more data sets. 

2. Ask the user to give average volume of data in those data sets 

"APPROXIMTELY HOW MANY INVOICES AT THIS POINT" 

(data set) 

3. If there is an order of difference between the two volumes 


then analyse as follows 
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^" 4 . Scan end locate the first data selection for a second data 
set. ‘""Scan backwards fren that point, by ignoring the 
procedures for calculations and any 'FOR EACH data, set ’ 
clause. Scar back only till sone other operation is found 

5. If no ’EACH data, set’ clause ms ignored in this process 
then abandon the analysis for the current data selection. 
Otherwise query the cardinality at the point of current 
scan as follows: 

"ROU MANY DIFFERENT VALUES HAS PRODUCT-CODE (the data item 
of data selection being analysed) FOR SET OE INVOICES 
(data set name at current scan point) AT THIS LEVEL?” 

6. 'AT THIS LEVEL' part can be refined specifically giving. 

all the sfeleetion data items of the subset blass at this stage 
like 

"INVOICES FOR A GIVEN CUSiaflER-NO 9 " 
y, If the answer is more than one then data selection under 

analysis can be shifted to just below the point of back scan. 

5-3* ANALYSIS OE UPDATE 

The system description often has omissions about strict update 
sequences, deletion facility, and the cycle of update. Updates are 
generally used on data which is about entities with long life time, 
data, which does not become obsolete after a time cycle and data 
about which deletion, up date etc. are needed as a result of the en- 
vironmental conditions. Sequence of different types of updates also 
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should bo specific, For example every nonth the selling price may 
be updated for a product, if there is data for such update. Suppose, 
due to soie policy of investment, returns and competition, it has been 
decided to slash the prices by one percent every six months. In this 
case, the precedence of six monthly and monthly updates will ha.ve to 
bo specified. One may of specifying it by declaring it as a data 
transformation at the beginning of the six monthly cycle. Such a 
dG.cl.Tration will implicitly make use of the convention th~t the begin- 
ning of a smaller cycle is later than that of the bigger cycle. For 
example, monthly processing at the beginning of a nonth will conven- 
tionally be done before the daily processing, on the day of the begin- 
ning of the month. 

Product-Form 
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Figure 5-1 : Updating Data Transformation. 
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Another problen in describing updates is illustrated in figure 
5-1 . This problen has also been pointed at the end of the Section 


5-1 . The problen is that of identifying whetllfa^*all the COST-MASTERS 
are newly created every day or only those for new products are crea- 
ted and added to tho ones already present. This problen can be algo- 
rithmically identified fron the descriptions in the fallowing my. 

1 . Do the following for all data sets. Check if an 
UPDATE, ADD or DELETE statanent is used. If these 
are used, then nark this data set as an entity 
oriented data set. 

2. Out of the remaining data sets select those which 
are being generated directly fron an input fom. 

If the data itens fron any of these sets are being 
used over a number of tine cycles then this is likely 


to be an entity oriented set. 

3. Eor all the data sets marked so far as entity 
oriented sets do the following steps. 

4. Check the cardinality handled by the creating process 


by creating the query : 

"APPROXIMATELY HOW MAHYCOST-MASTERS (data set none ) 

ARE CREATED 

EVERY TIME?" 

5 . Check the cardinality handled by the using processes 
by creating the query; 

"APPROXIMATELY HOW MARY COST-MASTERS (data set nane) 

ARE THERE?" 
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6. If the answer in Step 5 is greater than twice the 
answer in Step 4 then this data set is likely to 
be a growing set updated at tines. 

7. Take all the creating processes for the data set 
one by one and generate the following query 

"IS THIS COST-MASTER DATA TO BE ADDED, TO THE OTHER 
COST-MASTER (data set nand)DATA THAT IS ALREADY THERE? " 

8. If the answer to query in Step 7 is yes then change 
the CREATE to ADD and display to the user. If the 
user finds it unsuitable then he nay give the correct 
Torsion. If he accepts it then one nore display nay 
be node as in Stop 9. 

9. "THE VERY EIRST TIME THIS WILL BE CREATING A NEW 
COST-MASTER ALSO." 

5-4. CONCLUSION 

In conclusion it can be said tha.t the structure of the SDL can 
be exploited to algorithmically analyse the systen description. Such 
analysis has two cans. On the one hand it tries to get a logically 
correct and conpletc description and on the other hand it can gather 
Information for design and introduce changes to mke it suitc.ble for 
data processing. 

Sone methods of such analysis have been developed in this chapter. 
More such analysis can be systematically done if important data processing 
aspects of any description can be conceptualised. ■ 
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From the design point of view, it can be said that better opti- 
mization can be performed at a level at which the structure or the 
problem or the intent of the user is more clear. Designing of data 
partitions and processing programs is a difficult problem of optimization 
because for a data set, the organization and the accessing method of a 
computation using it, can not be determined independently of each other 
or of other data set organisations and computation accessing methods. 

The organisation of a data set limits the ways in which it can be 
practically accessed by a computation and the accessing method of a 
computation restricts the practicable organisation of a data set that 
it accesses. But business systems are highly sequential and the problem 
structure can be interactively used to collect the design information 


from the user. 



CHAPTER 6 


A CASE STUDY 

System description language should provide ease of use and a 
repertoire of concepts to describe all the relevant aspects of a 
number of users 1 systems* In this chapter a case study is deve- 
loped using the system description language presented in this thesis* 

A case study is taken fran !*CLI 1 ]. Due to some discrepancies found 
in the problem analysis, the problem has been modified. The selec- 
ted case study becomes difficult in terms of data descriptions, at 
certain points and illustrates that without the use of a host lan- 
guage, the system can be completely described in SDL* 

0-1 * PROBLEM DESCRIPTION 

A complete word statement of the case study is not being given 
here as it will take a lot of space and also it is a need of the formal 
description to be readable. Certain points which are Important In the 
case study are being described here. 

In the case study given here an information system is needed for 
a bakery to expedite implementation of changes in the customer require- 
ments and orders. Every day a list of all the commodities which are 
to be baked, is created. Bakery is used during the day to prepare 
confectionary items and during the night bread. Therefore, confec- 
tionary items to be sold the next day are loaded in the bakery in the 


morning* 


89 



90 


jivery day a list of the commodities in short supply is prepared. 
Orders related to these commodities are eliminated before the bakery 
load is prepared. After the items are ready in the bakery they are 
sent to six loading bays in sufficient quantity for each bay. There 
are delivery vans which have an associated round number (identifying 
the route allocated to a van) and a loading bay from which it gets 
loaded. Each customer is associated with a fixed round number accord- 
ing to the address and location. 

Vans make one or two deliveries on the same route according to 
the ordering requirements of the day. These vans have delivery-men 
incharge of the van who are given a delivery note for the day to 
deliver the orders to the cust oners. The orders which are not ful- 
filled due to non-availablity of the commodity are notified to the 
customer. In case certain items are not taken by a customer, inspite 
of the order or are taken extra by a customer, if available, then the 
delivery-men make a note of it and fill the returns and adjustment 
forms to be submitted to the bakery, immediately. 

The more complicated aspect is that of order collection which 
is also done by delivery— men. Orders are accepted on preprinted 
forms, OMR documents where the delivery man makes only a mark on 
the code provided. It has been done to simplify things for delivery' man 
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About 50 lines are accomodated on each form. There are about 1 20 
confectionary items which take three preprinted forms and one pre- 
printed form for bread items is sufficient. 

Every week, preprinted forms are created by the computer by 
additionally printing the day and the week on the preprinted form. 

Eor each day, the forms are printed. These are used over the week. 
Each form can be used to create the orders for all 6 days of the week. 
The commodity is identified by the line number on the form. If the 
order is temporary it is a temporary change to the standing orders, 
otherwise a permanent change. The system maintains standing orders 
for customers for all six days of the week for all the required 
commodities. Confectionary items have to be ordered two days before 
whereas bread items have to be ordered just one day in advance. 

6-2. HIP OEI'I ATI OH SYSTEM DESCRIPTION 

The relevant inputs, reports and data associations are described 
in the following pages. The documents and reports are partially 
described in figures to assist the reader. A flow diagram is being 
given in Figure 6-1 and Figure 6-2 to show the data transforma- 


tions 
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figure 6-1 

U sor's View of Overall Inf orm tion Fl ow 
(continued in Figure 6-2) 




Confectionery orders 
for day after tomorror; 


Bread orders for 

- ' tomorrow 



Updated standing 
orders 


Unavailable 
Confection ry orders 



for tomorrow 





Figure 6-2 

Us er’s Vie'; o f Over.:.!! Inf ora, tion H ow 
[Continued from Figure 6-1 - ) 
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VAN LOADING SCHEDULE POR 27 MARCH PAGE 13; 

DELIVERY BAY ROUND COMMODITY CODE £ DESCRIPTION QUANTITY 


1 A 18 001 13/4 LB THIN SLICED 57 

1 A 18 002 13/4 LB THICK SLICED ‘104 

1 A 18 

1 A 18 

1 B 20 



POR EACH DAY 

REPORT VAN-L 0 ADING- SCHEDULE 

EROM DATA SET DESPATCHED-ORDER : S OP TOMORROW CALLED ORDER :S 
POR EACH ROUND OP ORDER sS, ASCENDING BEGIN 

POE, EACH DELIVERY-NO OP ORDER :S, ASCENDING BEGIN 
POR EACfl COMMODITY OP ORDER :S BEGIN 
POR NEW-PAGE BEGIN 

VAN-LOAD-HEADING, TOMORROW (DAY OP MONTH BY NUMBER , 
MONTH OP YEAR BY NAME), PAGE-NUMBER 
NEW-LINE, '’DELIVERY BAY ROUND”, 

"COMMODITY CODE & DESCRIPTION QUANTITY" END 
DELIVERY-NO, BAY-NO, ROUND, COMMODITY. 

COMMODITY-DESCRIPTI ON , TOTAL OP QUANTITY END 
FORMAT "VAN LOADING SCHEDULE POR" PAGE-NUMBER PROM 45, 

D ELI VERY PROM 4, BAY PROM 10, ROUND PROM 16, COMODITY PROM 20, 

COMIODITY-DESCRIPTI ON PROM 26 , QUANTITY PROM 45 

OVER 
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BAKERY LOADING- SCHEDULE EOR 27 MARCH PAGE -j 

DAY-LOADING 

[COMMODITY CODE & DESCRIPTION BAY 

028 THREE IN ONE A 

B 
C 
D 
E 
E 

TOTAL 

031 SNOOPY SMALL PASTRY A 

B 
C 

EOR EACH DAY' " - — 

REPORT DAY-BAKERY-LOADING PROM DATA SET 
CUSTOMER-DELI VERY-C ONFECII ONARY : S OP DAY AFTER TOMORROW 

FOR EACH COMMODITY OF CONFECTIONARY-ORDER :S CALLED ORDER :S BEGIN 
FOR (l TO 6) LINES BEFORE END-OF-PAGE BEGIN 

HEA1ING, TOMORROW (DAY OF MONTH BY DUMBER, MONTH BY NAME) 
PAGE-NUMBER, NEW-LINE, "DAY LOADING", NEW-LINE 
"COMMODITY CODE & DESCRIPTION BAY QUANTITIES" END 
NEW-LINE, COMMODITY, COMMODITY-DESCRIPTION 
FOR EACH BAY BEGIN 

BAY, TOTAL OF QUANTITY OF ORDER :S AS BAY-TOT AL, NEW-LINE END 
TOTAL-HEADING, TOTAL OF QUANTITY OF ORDER :S AS COMMODITY- TOTAL END 
FOmfiT HEADING FROM 1 0 VALUE "BAKERY LOADING SCHEDULE FOR" 

PAGE-NUMBER FROM 45, COMMODITY SIZE 3, COMMODITY-DESCRIPTION 
FROM 10 SIZE 20, BAY FROM 25 SIZE 1, BAY-TOTAL FROM 30 
SIZE 4, TOTAL-HEADING FROM 23 SIZE 5 COMMODITY-TOTAL FROM 
29 SIZE 5 OVER 



QUANTITIES 

4975 

4168 

3430 

1800 

2445 

903 

17721 

1970 

3 
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BAKERY LOADING SCHEDULE POR 27 MARCH 
HI GHT-LO ADING 

COMMODITY CODE & DESCRIP HOF BAY 


PAGE i 

I 

QUANTITIES I 


001 1 3/4 BB THIN SLICED 


002 1 3/4 LB THICK SLICED 


A 

B 

C 

D 

E 

P 

TOTAL 

A 

B 

C 


3975 
1168 
4430 
2440 
1800 
304 
171 22 
1790 
4 


EOR EACH DAY 

REPORT NIGHT-BAKERY-LOADING SAME AS DAY-BAKERY-LOADING REPORT 
USING (OUST OMER-DELI VERY-BREAD : S OP TOMORROW 
FOR CUSTOMER-LELIVERY-COMFECTI ONARY : S OP DAY APTER TOMORROW, 
"NIGHT-LOADING" POR 'DAY-LOADING") 

OVER 
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DELIVERY ROTE POR 27 MARCH PAGE 1 


ROUND 

NO 

GROUP 

BRANCH 

COMMODITY-C ODE 
& DESCRIPTION 

QUANTITY 

DELIVERY 

18 

29 

004 

001 13/4 LB THIN SLICED 

57 

1 

18 

29 

004 

005 3 1/2LB SANDWICH 

20 

1 



EOR EACH DAY 


REPORT DELIVERY-ROTE 

is EROM DATA SET DE SPATC HfROTE : S OP TOMORROW 
POR EACH ROUND-RO, ASCEHDIRG BEGIR 

POR EACH (GROUP, BRANCH, COMMODITY) ASCENDING BEGIR 
POR REW-PAGE BEGIR 

ROTE-HEADIRG, TOMORROW (DAY OP MOUTH BY HUMBER, MOUTH BY HAME) 
PAGE-RUMBER, NEVA-LINE, PAGE-HEADIRG, NEW-LINE, HEADING- 2 END 
*ROURD-NO, GROUP, BRANCH 

COIMODITY, C OMMODIT Y-BE SCRIPTI OR, QUANTITY, DELIVERY END 
PORMAT ROTE-HEADING VALUE "DELIVERY ROTE POR" PROM 15, 

PAGE-HEADING VALUE 'ROURD-RO GROUND BRANCH COIMODITY CODE"- 
QUANTITY DELIVERY", IiEADIRG-2 "& DESCRIPTION" 

EROM 46, ROUND-RO SIZE 2 PR CM 2, GROUP PROM 9 SIZE 2 BRANCH PR CM 13 SIZE 3 , 
COMMODITY PROM 19 SIZE 3 C CMMODETY-DESCRIPTIOR PR® 23 SIZE 20 QUANTITY 
PROM 43 SIZE 2, DELIVERY P RCM 50 SIZE 1 OVER 


Data selection is based on day as a tine cycle. 

* This report can accomodate only one dispatch note for a day, 
for a given ROURD-RO, GROUP, BRANCH and COIMODITY and it can 
be an integrity constraint of the system. 
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HARTEE BAKERIES BID 

RQTOTOITo. WEEK/DAY ROmfpUc [j§EK f5~"~ DAY HO CODE 


27 23 BRI - - ■ 

(PREPRINTED EORM^ 



EOR EACH WEEK - - - "" 

REPORT ORDER- AldEKDIffilTT S-EOR-BREAE EROM DATA SET ROUND-NUMBER 


FOR EACH ROUND-NO ASCENDING BEGIN 
EOR EACH DAY OE WEEK BEGIN 
EOR 50 TIMES BEGOT 

NEW-PAGE AETER 5 LINES 

ROUND-NO, WEEK OE YEAR BY HUMBER, DAY BY NAME, 

*ROUND~CODE, WEEK-CODE, DAY-CODE, ITEM-CLASS EITD 
FORMAT ROUND-NO ERQd 6, WEEK EROM 11 , DAY EROM 14, ROUND-CODE EROM 18 
SIZE 6, WEEK-CODE EROM 24 SIZE 6 DAY-CODE EROM 30 SIZE 3 
ITEM-CLASS VALUE ZERO SIZE 2 EROM 34 OVER 


EOR EACH WEEK 

REPORT ORDER- AMENDEMENT S-EOR-C ONEEC TI ONARY-1 SAME AS 
ORDER-AMENDTIENTS-EOR-BREAD REPORT USING ( » -" EOR ITEM-CLASS) OVER, 

EOR EACH WEEK 

REPORT ORDER-AMENDMENT S-E dl-C ONEEC T I ONARY- 2 SAI® AS, 

ORDER- AMENDMENT S-E OR-BREAD REPORT USING ( "EOR ITEII-CLASS) OV ER 

EOR EACH WEEK REPORT ORDER-AMENDMENTS-EOR-C ONEECTI ONARY-3 _ 

SAJffi AS ORDER-/JIENDMENTS-E OR-BREAD REPORT USING " EOR ITEM-CLASS) OVbR 


*Encoding data transformations care needed for this 
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COMMODITY 

CODE 

100-1 25 


SALES REPORT POR AGGREGATE COMMODITY 
WITH INDIVIDUAL CUSTOMER GROUPS 
AND INDIVIDUAL WEEKLY VALUES 

RANGE 

PAGE 1 

CUSTOMER 

GROUP 

WEEKj5 

WEEK 6 

WEEK 7 

WEEK 8 

10 

11603 

10243 

9178 

8413 

12 

6451 

5 218 

4421 

4845 

15 

782 

660 

1199 

993 

16 

1395 

921 

996 


22 

536 

680 

770 

' 

25 

129 

230 



26 

488 

_ 




DOR EACH MONTH : 

liEPOBT SALES-OVEH-'iJEEKS EROM DATA SET DELIVERED-ORDERED:S OP WEEK-SET-1 

SUB-REPORT- 1 REPORT 

EOR EACH COMMODITY-SET BEGIN 

NEW-LINE, SPACE 2, COMODITY-C CEDES (SIZE 7) 

POR EACH GROUP ASCENDING BEGIN 
GROUP 

POR EACH WEEK-OP-DELIVERED-ORLER : S , ASCENDING (4 COLUMNS OP 
ft SIZE 16 PROM 36) BEGIN TOTAL OP QUANTITY END 
NEW-LINE 

POR NEW-PAGE BEGIN 
SUB-REPORT- 1 REPORT 
NEW-LINE, fQ OMtfODITY-SET END 

PCERMuT COMEODITY-SET PROM 2 SIZE 7, GROUP PROM 14 SIZE 2 TOTAL PROH 
10 SIZE 6 OVER 


*WEEK- SET-1 is a user invented tine duration, to be described. 

|If group num ber continue on a new page then C CMMODITI-SET is to 
be repeated once more, 

tflflultipl e instances of data may be formatted vertically or horizontally. 
Por horizontal formatting a page may be divided into repeating columns. 
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'■-RE PORT SUB-REPORT -1 EROH DATA SET Nil 
M NEW--PAGE BEGIN 

BLANK 2, "SAIES REPORT EOR AGGREGATE GOIffliODITY RANGE" 
SP/CE 10, PAGE- NUMBER, ME'V-LINE, SPACE 14, 

"WITH INDIVIDUAL CUSTOMER GRCOPS", NEW-LINE, SPAiCE 16, 
"AND INDIVIDUAL WEEKLY VALUES” NEV-LIHE, SPACE 2, 
"COMMODITY CUSTOMER WEEKS WEEK6 V.EEIC7 WEEKS ” 

NEW-LINE, SPACE 4 "CODES GROUP" END 
OVER 


**■ New page description being a lengthy description, is 
difficult to repeat and is described as a secondary- 
report which does not have an associated condition 
l'or its production. 
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SALES REPORT FOR SEPARATE COMMODITIES 

WITH INDIVIDUAL CUSTOMER GROUPS AND 

AND AVERAGE QUANTITIES 

Pi.GE 1 

COMMODITY 

CUSTOMER 

AVERAGE OVER 


CODE 

GROUP 

MONTH 13-24 


104 

00 

156204 


104 

01 

30821 


104 

02 

14528 


108 

00 

1 1 6983 


108 

01 

1 240- -- 



FOR EACH MONTH 

REPORT C OMMODI T Y- SALES FROM DATA SET DELIVERED-O BDER :S OE MONTH-SET-1 
EON EACH C CMMODITY, GROUP-NO , ASCENDING BEGET 
FOR NEV-PAGE BEGIN 

HEADING-1 , PAGE-NUMBER, NEW-1INE, HEADING- 2 
NEVA-LINE, HE/DING-3 END 
COMMODITY 
GROUP-NO 

TOTAL OF QUANTITY END 
FORMAT 

IIEADING-1 VALUE "SALES REPORT FOR SEPARATE COMMODITIES » FORM 8 
HEADING- 2 FROM 10 VALUE "WITH INDIVIDUAL CUSTOMER GROUPS" 

IIGADING-3 VALUE "AND AVERAGE QUANTITIES" FROM 15 COMMODITY SIZE 3 FROM 9 

GROUP-NO SIZE 2 FROM 1 9 TOTAL SIZE 1 0 FROM 24 

OVER 
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MONTHLY INVOICE 

INVOICE NO: 3935 BILLS: 35 MARCH 

CUSTOMER NAME : A.D. MICHAEL 


CUSTOMER ADDRESS 
S.N. DATE 
1 5/3/77 

FOR EACH MONTH" ' 


: FLAT 29, STREET 5Q, 

LONDON 

COMMODITY ORDER AMOUNT 


1 3/4LB THIN SLICED 5 21 .00 




REPORT INVOICES FROM DATA SET BILL:S OF CURRENT MONTH 
FOE EACH CU STOMER-C ODE BEGIN 

NUMBER ON DATE ASCENDING AS BILL-NUMBER , CURRENT MONTH BY IDLE 
INCREMENT INVOICE-NO BY 1 
COUNT BILL : S AS BILL-COUNT 


NEW-PAGE, SPACE 10, 'MONTHLY INVOICE" NEW-LINE 
"INVOICE NO : " INVOICE-NO, " BILLS : "BILL-COUNT 
NEW-LINE, "CUSTOMER NAME : " OUST CMER-NAME 

NEW-LINE, "CUSTOMER ADDRESS : » ADDRESS-LINE-1 , 
NEW-LINE, ADDRESS-LINE- 2, NEW-LINE, HEADING 
FOR EACjI BILL BEGIN 


FOR NEW-PAGE BEGIN 

"INVOICE NO: " INVOICE-NO 


NEW-LINE, HEADING END 
NEW-LINE, BILL-NUMBER, DATE, COMMODITY 
QUANTITY, VALUE END 
NEW-LINE, "INVOICE NO" INVOICE-NO, 

SPACE 3, "TOTAL" TOTAL OF AMOUNT 
F CRM AT INVOICE-NO SIZE 4, BILL-COUNT SIZE 2, 

CUSTaffll-NAME SIZE 20, ADDRESS-LINE-1 SIZE 30 
ADDRESS-LINE-2 SIZE 30, HEADING 

"S.N. DATE COMMODITY ORDER AMOUNT " 

BILL-NUMBER SIZE 2, DATE FROM 4 SIZE 8, COMMODITY 
FROM 14 SIZE 25 QUANTITY FROM 40 SIZE 2, VALUE 
FROM 44 PICTURE 99.99, TOTAL PICTURE 9999.99 OVER 
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preprinted omr rocmgar 

l hartee bakeries istd\. bifiiingham 

, 2 


AMENDl'lENTS 


ROUND NO. WBEK/DAY 


27 


23/FRI 


ROUND-NO 
CODE 


WEEK-NO 
CODE 


' T r7_; ' r 


DAY 

CODE 


CD 


BREAD : 
orDEEs; 
I 

i 


C E 

0 I 

^ DESCRIPTION J 

J'j E 

TENS [UNITS. HUNDRED TENS UNITS I 

-2-1 -6-3-2-1 t3-2— 1 43-2-1 46-3-2-1 1 ] 

QUANTITY 

iTUFDRE-ns .TENS UNITS AMEND DAYIS) _ 

TTOT'I'iilN SEIUlD 10B“'' 

. i 

| -D- 5 -£- 1 -0-3- 2-1 -P-+— - M-l'-W-ti-Ji'-S 

002 SANDWCICH 1 2P i 

-6-3- 2-1 -6-3- 2-1 -6-3- 2-1 -P-+ T — M-T-T-H-E-S 

003 TINS 20P 

* * * « « 4 * • ■ « « t 

004 LONG BATCH 23P 

005 BROWN BATCH ... 



FOR EACH DAY 

D OCUMENT OlfflER-AIJENDMGNTS 10 DATA SET TYPE-B1 :S 
FOR EaCH 50 TYI-’E-BI :S BEGIN REQUIRED ALL 
HEW-P0I<I1, AFTER 5 LINES 

HOUND-NO , WEEK-NO, DAY-IIO, ROUND-NO-C ODE , WEEK-NO-CODE 
DAY-NO-CODE, ITEM-CLASS, FEW-LINE, GROUP-CODE, BRAKE-CODE 
FOR EACH OE TYPE-B1 : BEGIN 
FEW-LIFE 

POD B-1 -DATA = SPACE BEGIN UNFILLED, IGNORE END 
EPIC 3-1 -DATA NOT = SPACE BEGIN 
REQUIRED ALL, NEW-LINE 
MAKE C OMLIODETY-LINE = LINE-NUMBER, 

QUANTITY-CODE, AMENDMENT-0 ODE , AMENDMENT-TYPE, 

AMENDMENT-BAYS END 

EURMAI ROUND-NO ERCM 5 SIZE 2, WEEK-NO FROM 10 STZE 2 VALUE CURRENT 

WEEK OF YEAR BY NUMBER, DAY-NO FROM 1 2 SIZE 3 VALUE CURRENT 

DAY BY NAME ROUND-NO-CODE FROM 17 SIZE 6 WEEK-NO-CODE EROM 

23 SIZE 6, BAY-NO-CQDE FROM 29 SIZE 3-ITEM-CLASS PRCM 32 SIZE 2 

GROUP-CODE FRCM 17 SIZE 6 BRANCH-CO DE EROM 23 SIZE 6 

QUANTITY-CODE FROM 17 SIZE 12 AMENDMENT-CODE FROM 29 

SIZE 1 , AMENDMENT-TYPE FROM 30 SIZE 2 AMENDMENT-DAYS FROM 32 

SIZE 6, B-1 -DATA FROM 17 SIZE 21 

OVER 


P AMENT S-RECEIVED 


ACCOUNT-NO 

15 


diASS-OF-TRANSACTION PATE AMOUNT 



POll EACH MONTH 

DOCUMENT PAYMENT-RECEIVED TO DATA SET TYPE-® 

POR EACH 15 TYPE-B5 :S BEGIN 

NEW-PORM, APTER 3 DINES 
POR EACH TYPE-® BEGIN 
NEW-LINE 

POR B5-DATA = BLANK BEGIN UNFILLED, IGNORED END 
POR ® -DATA NOT = BLANK BEGIN 

REQUIRED ALL, ACCOUNT-NO, CL ASS- OF-TRA NS AC TI ON 

AMOUNT MID 

PORI, LIT B5-DATA PROM 2 SIZE“26, ACCOUNT-NO PROM 2 SIZE J JALUE^MPffiPR, 
CLASS-OP- TRANSACTION PRCM 9 SIZE 1 VALUE RANGE 1 TO 6, DA^® 

SIZE 6 VALUE (ZERO TO CURRENT DATE) AMOUNT PROM 18 PIC 999.99 VALUE 

NUMBER OVER 


l?OH UACII DAY 

DOCU MEN T RETURN-ADJUSTMENTS SAME AS ORDBR-AMENDYENIS 
DOCUMENT USING (NIL POR AMENDMENT-CODE, TYPE-3 P°R TYPE-1 ) 


OVER 
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DATA-DESCRIPTION 


BREAD- ORDER : S DEFINED AS ORDER :S 
C ONFECTI ONARY-ORDER : DEFINED AS ODDER sS 
OVER 


DAIA-DESCRIP H ON 

PERIOD YJEEK- SET-1 IS FROM 8 PEEKS BEFORE CURRENT-REEK 

TO 4 WEEKS BEFORE CUIIEENT-YEEK 
OVER 


DATA-DESCRIPTION 
FOR ORDER : S BEGIN 
FOR EACH ORDER BEGIN 
FOR COMMODITY OF ORDER 
MAKE C OMMODIT Y-SET - 
FOR CCWMODITY OF ORDER 
MAKE COMMODITY- SET = 

OVER 


1 1 00 OR £ 1 25 BEGIN 
”100-1 25 " END 
>125 BEGIN 
"125-165" END 


DATA-DESCRIPTION 

PERIOD MONTH-SET-1 IS FROM 24 MONTHS BEFORE CURRENT-MONTH 

TO 1 2 MONTHS BEFORE CURRENT MONTH 
OVER 


COMMENT : There is very conplicated decoding of ORDER forn 

and therefore the next few data description modules 
happen to be mostly procedures. 
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DATA-RESCRIPTION DECODING-ORDERS PROM DATA SET TIPE-B1 -OF TODAY 
FOR EACH TYPE-B1 :S BEGIN 

SAME AS BIN/HY DaTA-BE SCRIBTION USING (ROUND-NO-CODE FOR CODE, 
ROUND-NO FOR VALUE) 

SAME AS BINARY DATA-DES CRIPTI ON USING (WEEK-NO-CODE FOR CODE, 

UEEK-NO FOR VALUE) 

SAME AS BINjiRY DATA-DESCRIPTI ON USING (DAY-NO-CODE 
FOR CODE, DAY-NO FOR VALUE) 

SAME AS BINARY DATA-DESCRIPTI ON JJSING (ITEM-GLASS 
FOR CODE, ITEM-NO FOR VALUE') 

MAKE GROUE-NO = 0 

SAME AS CODE- 21 DATA-DESCRIPTI ON USING (POSITION 1 TO 2 OF GROUP-CODE 
FOR CODE, GROUP-NO FOR VALUE) 

SAME AS CODE-6321 DATA-DESCRIPTI ON USING (POSITION 3 TO 6 
OF GROUP-CODE FOR CODE, GROUP-NO FOR VALUE) 

MAKE BRANCH-NO = 0 

SAME AS CODE-321 DATA-DESCRIPTI ON USING (POSITION 1 TO 3 
OF BPAiNCH-O; BE FOR CODE, BRANCH-NO FOR VALUE) 

SAME AS CODE-321 DATA-DESCRIPTI ON USING (POSITION 4 TO 6 
OF BRANCH-CODE FOR CODE, BRANCH-NO FOR VALUE) 

SAME AS CODE-6321 DATA-DESCRIPTI ON USING (POSITION 7 TO 10 OF 
BRANCH-CODE FOR CODE, BRANCH-NO FOR VALUE) 

MAKE QUANTITY = 0 

SAME AS CODE-6321 DATA-DESCRIPTION USING (POSITION" 1 TO 4 OF 
QUANTITY-CODE FOR CODE, QUANTITY FOR VALUE) 

SAME AS CODE-6321 DATA-DESCRIPTION USING (POSITION 5 TO 8 OF 
QUANTITY-CODE FOR CODE, QUANTITY FOR VALUE) 

SAME AS CODE-6321 DATA-DESCRIPTION USING (POSITION 9 TO 1 2 OF 
QUANTITY-CODE FOR CODE, QUANTITY FOR VALUE) 

CREATE DEC0BED-B1 (ROUND-NO, WEEK-NO, DAY-NO, ITEM-NO, GROUP-NO, 
BRANCH-NO, QUANTITY) 

END OVER 


COMMENT : Reference to a part of a data item can be made by POSITION. ^ 
The same data could have been described in the input document 
by using a num ber of data nones, to avoid a partial reference. 
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D/ITA-DESCRIPTlfe BINARY 
MAKE VALUE = 0 


FOR POSITION 1 of CODE = 
FOR POSITION 2 OF CODE = 
FOR POSITION 3 OF CODE = 
FOR POSITION 4 OF CODE = 
FOR POSITION 5 OF CODE = 
FOR POSITION 6 OF CODE = 
OVER 


1 BEGIN ADD 32 TO VALUE END 
1 BEGIN ADD 1 6 TO VALUE END 
1 BEGIN ADD 8 TO VALUE END 
1 BEGIN ADD 4 TO VALUE END 
1 BEGIN ADD 2 TO VALUE END 
1 BEGIN ADD 1 TO VALUE END 


DATA-DESCRIPTIQN CODE-6321 
MAKE C IECK = 0 

FOR POSITION 1 OF CODE = 1 BEGIN ADD 
FOR POSITION 2 OF CODE = 1 BEGIN ADD 
FOR POSITION 3 OF CODE = 1 BEGIN ADD 
FOR POSITION 4 OF CODE = 1 BEGIN ADD 
ADD CHECK TO VALUE OVER 


6 TO CHECK END 
3 TO CHECK END 
2 TO CHECK END 
1 TO CHECK END 


DATA-DESCRIPTIQN GET- VALUE 

FOR CHECK < 1 0 BEGIN MULTIPLY CHECK. BY 1 0 

ADD CHECK TO VALUE END 


OVER 


DATA-DESCRIPTIQN CODE-321 
MAKE CHECK = 0 

FOR POSITION 1 OF CODE = 1 BEGIN ADD 3 TO CHECK END 

FOR i OSITION 2 OF CODE = 1 BEGIN ADD 2 TO CHECK END 

FOR POSITION 3 OF CODE = 1 BEGIN ADD 1 TO CHECK END 
SAME AS GET- VALUE DATA-DESCRIPTIQN 
OVER 

PATA-DESCRIP H ON CODE- 21 
MICE CHECK =0 

FOR POSITION 1 OF CODE = 1 BEGIN ADD 2 TO CHECK END 

FDR POSITION 2 OE CODE = 2 BEGIN ADD 1 TO CHECK END 

~SAME AS GET-VALTJE DATA-DESORIP TI ON 
OVER " 


DATA-DESCRIPTI ON C ODE-63 21 1 , N 

"SAME AS CODE-6321 DATA-DESCRIPTIQN USING (NIL FOR ADD CHECK TO ViEUEJ 

SAME AS GET-VALUE DATA-DESCRIPTIQN 
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DATA-DESCRIPTI OH DECODOTG-THE-DAY-AND-C Cf'f IODITY-CODE 
FOR DEC0DED-B1 :S, COMMODITY-SET :S BEGOT 
FOR EACH DEC0DED-B1 BEGOT 

FOR AMENDEMENT-TYPE / "11” BEGOT 

FOR DAY-NO = CURRENT DAY OF WEEK BY NUMBER BEGIN 
FOR WEEIC-NO = CURRENT WEEK OF YEAR BY NUIIIL'R BEGOT 

FOR COMMODITY-SET (ITEM CLASS = ITEM-CLASS OF DEC0DED-B1 , 
C QfflODITY-LINE = COMMODE TY-LINE OF DEC QDED-B1 ) BIGOT 
COMMODITY = COMMODITY OF COMMODITY-SET 
REDESCRIBE AMENDIIENI-DAYS BEGIN 
AMENDMENT-DAY REPEATED 6 TIMES END 
NUMBER . DECQDED--B1 _ AS DAY-COUNT , _____ 

FOR EACH DEC0DED-B1 BEGIN FOR AMENDMENT-DA Ip 0 BEGlh 

CREATE ACCEPTED-AMENDMENT (DAY-COUNT) 

END OVER 


COMMENT: Besides the DAY-COUNT the other data itens associated with ACCEPTED- 
AMENDMENT are being assumed by the user, for the tine being. 


DAT A-DESCRITT I ON NIL 

FOE ACCEPTED-AMENDMENT :S OF CURRENT DAY BEGIN 
FOR EACH ACCEPTED-AMENDMENT BEGIN 

FOR AMENDMENT-CODE = "1 " BEGOT CREATE PERMANENT-AMENDIffil® END 
FOR AMENDMENT-CODE = 0 BEGIN CREATE TEMPORARY-AMENDMENT END 
OVER 


COMMENT : The ACCEPTED-AMENDMENT at this point has two tine tags. It is 
today's amendment because it'»heen accepted today. Also, it 
na y be an amendment for a Friday order. This second tine tag 
is kept as a data item DAY-CQJNT in the description. 


•^Repeating 
for other 


of the field creates a set of 6 DECODE D-B1 , 
processing statements at this level. 
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DATA-DESORIPTION UPDATING-STANDING-OREERS 

you permnent-amendments, standing-order : s begin 
for each vmwmr-jmmmm begin 

FOR STANDIN G-ORDER (GROUP-CODE, BRANCH-CODE, COMMODITY', 

DAY-COUNT = ALL OP PEHIANENT-AMERDMENT) BBGIil 
FOR STANDING-ORDER PRESENT BEGIN 
FOR AMENDMENT-C ODE = "10" BEGIN 

MAKE QUANTITY = QUANTITY OP STANDIITG-ORDER 

ADD QUANTITY OP PERMNENT-AMENDMENT TO QUANTITY END 

FOR AMENDMENT-C CUE = "01 " BEGIN 

FOR QUANTITY OP PERMANENT-AMENDMENT 
QUANTITY OF STANDING-ORDER BEGIN 
MAKE QUANTITY = QUANTITY OF STANDING-ORDER 
SUBTRACT QUANTITY OF PERMANENT-AI'lENDI'/lEITT FROM QUANTITY 
END END 

FOR AMENDMENT -C ODE = "00" BEGIN 

MAKE QUANTITY = QUANTITY OF PERtRJIENT-ABIEHDI'IENT END 
* UPDATE STANDING-ORDER (QUANTITY = QUANTITY) 

END 

FOR STANDING-ORDER ABSENT BEGIN 
FOR AMENDMENT-C ODE = ”00” BEGIN 

CREATE STANDING-ORDER (QUANTITY, GROUP-CODE, BRANCH-CODE, 
C OMM ODITY, DAY-COUNT = ALL OF PERMANENT-AMENDPMTO ) END 

OVER 


COMMENT : The presence and absence of standing orders is checked here 
because the actions are specific. The user nay forget to 
describe what is to be done in case of absence generally. 


* QUANTITY at the right hand side may be of PERliIANENT-iu.IENDlviii.NTS 
or of STANDING-ORDER. 
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ON CIIEATIITO-TEIIPORARY-ORDERS SAME AS UPDATING STANDING- ORDERS 
DATA-DESCRIPTI ON USING (TE€PORARY-AiMU}MENT 
FOR PERMANENT-AMENDMENT , 

CREATE TEMPORARY- ORDER POR UPDATE STANDING-ORDER, 

CREATE TEMPORARY ORDER POR CREATE STANDING-ORDER) 

OVER 


PAPA-DESCRIPTION TE^OiRUlY-ORDER-HANDLING 
PERIOD DAY OP WEEK BY NUMBER IS DAY-COUNT, 

OP TEMPORARY-ORDER 

PERIOD WEEK OP YEAR IS CURRENT WEEK, OP TEMPORARY-ORDER 

PERIOD YEAR IS CURRENT YEAR, OP TEMPORARY-ORDER 

PERIOD DAY OP WEEK BY NUMBER IS DAY-COUNT, OP STANDING-ORDER 

OVER 


COMMENT! The tine tag declaration here specifies two things - 
1 . It converts a data iten DAY-COUNT to tine $ag 
2. On standing orders the tine tag is only within 
a weeKLy cycle and shows that Monday’s orders 
bee me today's orders every Monday. This is not 
so for tenporary orders which exist only one Monday. 
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DATA-DBSCRIPTI ON KINDS-OF-STANDING-ORDERS 
FOR STANDING-ORDER : S BEGIN 
FOR C QMODITY < 1 0 BEGIN 

STANDI NG-ORDER : S DEFINED AS BEEAD-STANDING-OEDER : S END 
FOR COMMODITY >10 BEGIN 

STANDING-ORDER :S DEFINED AS CONFECTI CNARY-STANDING-OEDER : S END 

OVER 

DATA-DESCRIPTION ED NDS-OF-TEMPORARY-ORDERS 
FOR TE MPORARY-ORDER : S BEGIN 
FOR COMMODITY < 1 0 BEGIN 

TEMPORARY-ORDERS DEFINED AS BEEMD-TEMPOEARY-OEDER : S END 
FOR COMMODITY > 10 BEGIN 

TEMPORARY-ORDER :S DEFINED AS CONFECTI ''NARY-TEMEORARY-ORDER :S 

END " ' ~~ 

OVER 


DATA-DESCRIPTION PREP/RING-ORDERS-FOR-BREAD 
FOR EACH DAY 

FOR BrDEAD-TEMPORARY-OEDER : S OP TOMORROW, 

BREAD- STANDING-ORDER :S OE TOMORROW BEGIN 
FOR EACH STANDING-ORDER BEGIN 

FOR BREAD-TEIffiORARY-ORDER (GROUP-0 ODE , BRANCH-CODE, 
COMMODITY = AIL OF BREAD-STANDING-ORDER ) BEGIN 
FOR BREAD-TEffl?ORARY~ORDER ABSENT BEGIN 

CREATE BREAD-ORDER (ALL OF BREAD-STANDING-ORDER J 
PERIOD OF BREAD-ORDER IS TOMORROW 
END END END 

PCR EACH BREAD-TEMPORARY-ORDER BEGIN 

CREATE BREAD-ORDER (ALL OF BREAD-TEC, 5P0RARY-0RDER ) 
PERIOD OF BREAD-ORDER IS TOMORROW 

OVER 


DATA-DESCRIPTION PREP ATJNG-ORDERS-POR-C ONFECTI ( 'NARY 
SAME AS PREPARING-OEDERS-FOR-BREAD DATA-DESCEIPIEON USING 
TmY AFTER TOMORROW FOR TOMORROW, C ONFECTI ONARY-OEDER 
FOR BREAD-ORDER, CONFECTIONARY-TEC, HORARY-ORDER FOE 
mffiAD-TEMPORARY-OEDER, C ONFECTI ONARY-STANDING— ORDER 
FOR BREAD-STANDING-ORDER) OVER. 
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BETA-PESO RIPTI Oil BREAD-OID3ERS-TO-BE-DELIVERED 
BOR BI1EAB-ORDER : S OP TOMORROW BEGIN 

POR UNAVAILABLE-COMMODITY : S OE TODAY BEGIN 
EOR EACH BREAD-ORDER BEGIN 

POR UNAVAILABLE-C OMMODIT Y (COMMODITY = C QvMODITY-C ODE 
OP BREAD-ORDER) BEGIN 
POR UNAVAILABLE-COMMODITY PRESENT BEGIN 

CREATE UNAVAILABDE-BREAD-ORDER (ADD OP BREAD-ORDER ) 
PERIOD OP HN AVA HABLE-BREAD-ORDER IS TOMORROW END 
POR UNaVAIL ABLB-C (BLIODITY ABSENT BEGIN 

CREATE CUST CMER-DELIVERY-BREAD = (ADD OP BREAD-ORDER ) 
PERIOD OP CUSTOMER-DELIVERY-BREAD IS TOMORROW END 

OVER 


COMMENT: At this point unavailable commodities remain as a data for 
which no input is defined. Very low volume data often has 
no staixlard input forms. 


DAIA-DESORI P II ON C ONPECTI ONARY- OTiDERS-TO-BE-DEDI VERED 
SAKE AS Bi'.i/j)-OI®ERS-TO-BE-DELIVEEED DATA DESCRIPTION USING 
‘(0 ONPECTI ON ARY-ORDER. : S POR BREAD-ORDER :S, DAY APTER TOMORROW POR TOMORROW, 
OU 3T0MER-DELI VERY-C ONFEC TI ONARY POR CUSTOMER-DEIIVERY-BREAD) 

OVER 


DATA-DESCRIPTION ROUND-DELIVERY-NOS 
POR EACH DAY 

POR GUST QAER-DEIIVERY-BREAD :S OF TOMORROW CALLED ORDER :S, 

CUST aiER-DEDIVERY-C ONPECTI ONARY OP TOMORROW CALLED ORDER sS BEGIN 
POR EACH ROUND-NO OP ORDER sS, DEGIN 
MAKE DEHVERY-NQ = 1 
MAKE LOADING-SPACE = VAN-CAPACITY 
POR EACH ORDER BEGIN 

POR SIZE-POINTS OP ORDER > LOADING-SPACE BEGIN 
INCREMENT DELIVERY-NO BY 1 
MAKE LOADING-SPACE = VAN-CAPACITY END 
DECREASE LOADING-SPACE BY SIZE-POINT OP ORDER 

CREMATE DESP ARCHED-ORDER (DELIVERY = DEDIVERY-NO, ALL OP ORDERS ) 
PERIOD" OP DESPATCH-ORDER IS TOMORROW, 

END 

OVER 


DATA-DESORPTI ON NIL 

UNAVAIMBLE-BREAD-ORBER : S DEFINED AS DESPAlCH-NOTm 
UNAVAILAELE-ODNPECTI01I1RY-ORDER:S DEFINED AS DESPATCH-NOTE 
DESPATCHED-ORDER DEFINED AS DESPATCH-NOTE 
OVER 
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DATA-^BSCHPTIOH ReTURNS-CHECICENG 

S/J.IE AS DECODING-ORDERS DATA-DESCRPTION USING 

( T YI E— D3 FOt TYPB-B1 , DECODED— B3 POE DECODED-B1 ) 

OVEE 

DATA-DESCllIPTION DECODING-DA Y-PGt-RETURNS 
SAME AS DECODING-DAY DATA-DESCRPTION USING 

(DECODED-B3 POE DECODED-B1 , ACCEPTED-RETUM FOR ACCEPTED-M1ENDMENT ) 
OVEE 


DAIA-DESCRIPTI ON PERIOD-OF-RETURN 
POE ACCEPTED-RETURNS DO? TODAY BEGIN 
ZOli DAY-COUNT OP ACCEPTED-OEDEE = YESTERDAY OP WEEK BY NUMBER BEGIN 
ACCEPTED-RETURN DEPINED AS RETURN END 
OVER ’ “ 


COMMENT: Here day count is not used to declare a period but for data 

of 

cel action. Period of RETURN by default is thnt/>OOEPTED- 

RETURN. It implies that lebims have to come within a day. 

DATR.-DESORIPTIO N UPDATING-DELIVERY 
POE RETURN :S POR TODAY BEGIN 

POE BES EATCHED-ORRER : S OP YESTERDAY BEGIN 
POE EACH RETURN BEGIN 

POR DESPATCKED-ORBER (GROUP-NO, BRANCH, COMMODITY = ALL OP RETURN ) 

EDGE IT 

POR DESPATCIIED-ORDER PRESENT BEGIN 
FOR AMENDMENT-CODE = "10" BEGIN 

ADD QUANTITY OP RETURN TO QUANTITY OP DESPnTCIIED-ORDER 
GIVING NEW-QUANTITY END 
POR AiENDUENT-C ODE = "01 " BEGIN 

POR QUANTITY OP DESPATCHED-ORDER NOT < QUANTITY OP 
RETUW BEGIN 

SUBTRACT QUANTITY OP RETURN PROM QUMTITY OP DESPATCHDB-ORDER 
GIVING NEW-QUANTITY END 
END 

CREATE DELI VERED-OEDER (QUMTITY = NEW-QUANTITY, ALL OP 

DESPATCHED-ORDER) 

PERIOD OP DELIVERED-ORDER IS YESTERDAY END 

OVER 


COMMENT: In the above description, from todayfe returns, yesterday's 
corrected DELI VERED-ORDEES have been created. 
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DATA-DESCRIPTION PINAL-DELT VE RED -O RDER S 
ROR DESPATCHED-ORDER : S OP YESTERDAY, 

DELIVERED-ORDER:S OE YESTERDAY BEGIN 
EOR EACH DESPATCHED-ORDER BEGIN 

P® DELI VERED-ORDER : S ( GROUP BRANCH, COMMODITY 

= ALL OP DESPATCH-ORDER) BEGIN 

POR DELIVERED-ORDER ABSENT BEGIN 

CREATE DELIVERED-ORDER = (ALL OP DESPATCHED-ORDER) 

END 

OVER 


POR EACH MONTH 

DATA-DE SCRIPTI ON CREATION-OP-BILL 
POR DELIVERED-ORDER :S OP CURRENT MONTH,' 

COMMODITY-SET :S BEGIN 
POR EACH COMMODITY-SET BEGIN 

POR DELIVERED-ORDERS (COMMODITY = COMMODITY-CODE OP COffllODITY-SET ) 

BEGCN 

POR EACH DELIVERED-ORDER BEGIN 

MULTIPLY QUANTITY OP ORDER BY PRICE OP 
COMMODITY-SET GIVING AMOUNT. 

CREATE BILL (AMOUNT = AMOUNT, ALL OP DELIVERED-ORDER) END 

OVER 


END-OP-DESCRIPTI ON 


COMMENT: CCMIODITY-SET is also used as a 
domain elsewhere. 


6-3. CONCLUSION 

This case study has a fairly complicated timing requirement and 
data selection. It also requires a lot of calculative description due 
to the need to decode forms. It has very special requirement in terms 
aC timings. 

The description shows that it is possible to describe all the 
necessary aspects of a real life information system without making 
use of c cement s or host language procedures. Such a statement can be 
used for the analysis of data requirements etc. 



CHAPTER 7 


CONCLUSIOIS 

Information systen design for administrative systems lias always 
taken enormous tine and nan-power. Most often, the reason for this is 
a communication gap between the user and the systen analyst, created 
by an inadequate description of the user's problen. This calls for 
many iterations during various phases of the systen development cycle. 

The problem of reducing the tine and efforts required for the informa- 
tion system development has been taken up in this thesis. Hie main 
idea is to introduce the computer as a tool, in the systen development 
cycle . 

A lot of work is being done in this direction. Systems like 
ISDOS and HICTC„ SYSTEM-1 BOTTOM PART etc., are some of the systems, which 
havo tried to achieve this, by taking up the automation of the design 
phase as the main task. Autonation of problen acquisition phase is 
being tried in two different ways : one is that of describing the 
functions cf the organisation, and the other is that of using languages 

with tuple-oriented data, selection. 

In this thesis a high level language is developed for describing 
information processing systems. This language has features for des- 
cribing the inputs, outputs, data transformations and system timings 
with the help of data oriented control structures. It is shown that 
business processing systems can be completely described in this language 
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without the help of procedures written in host languages, All the 
features of this language are based on two underlying concepts. 

1 . User should be allowed to specifically describe all the 
interactions of the information processing systen, with his organi- 
sation. ®iio infomation could be such as update timings or instruc— 

tionofor picking up line numbers from a document to be used as product- 
codes. 

2. Business systems are concerned with classes of subsets of 
data. Mechanisms of data selection and generation for such subsets are 
essential for high level systen descriptions. This fact has not been 
recognized in the existing literature. 

It is shown that algorithmic analysis of the kind, done by other 
system like ISDOS, con. be done on systen descriptions given in the 
language described in this thesis. The data needs can be identified 
and c.'ji be matched with the data availability. It is also shown that 
real life systems analysis is much more than mechanically checking 
for the presence of required data items. 

It is established that the block-structure of SUL can be exploited 
to algorithmically analyse the systen description to generate questions 
about the systen for doing the following: 

1 . To guide the user to give more correct descriptions 
of the system, 

2. To got design information from the user related to 
data cardinality and integrity. 
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It is felt that to analyse and design information systems, it 
is important to understand the purpose of data trnnsfo motions. It 
has been seen that in the model building approach, the descriptions 
become a largo set of snail concepts. Putting the pieces together, 
without a mechanisms for structuring, is very difficult, further 
work is to be done to work out better user interfaces. But they 
will be useful only when data oriented structural descriptions and 
not property oriented descriptions are given. Few concepts to 
enrich the user interface vocabulary nay be developed. Hie concepts 
should be abstracted in a manner usable for data processing. Here 
we have developed the subset concept. Similarly an abstraction which 
could identify real entities is very nuch needed. In this thesis, 
tine has been abstracted to a usable level. Similarly, a generalised 
concept for ’measure’ could be developed. These abstractions could 
make the level of the description less clerical and more managerial. 

It will also be very useful if a generator could be developed 
which may not use very efficient design strategies but may atleast 
crCcate one feasible design and generate the desired information 


processing system 
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APPENDIX I 


1 24 


100300 GRAMMER DEFINITION. 

1 005 00 GiARMER-ID . REPORT . 

100700 OPTIONS ARE LIST NODES XREP COMPILE. 
100900 DEPINE SIZE TEXT = 80 DYTES. 

101100 DEFINE SIZE ENTITY =30 BYTES. 

101330 DEFINE SIZE STACK = 9 ENTIES . 

101500 PROCEDURE LIST. 

101700 DATA-NEED. 


1 01 900 
102100 
102300 
102500 
102700 
102900 
103100 
1 03300 
103500 
103700 
103900 
104100 
104300 
104500 
1 04700 
104900 
105100 
105300 
1055 00 
105700 
105900 
106100 
106300 
106500 
1 06700 
106900 
1 071 00 
107300 
107500 
1 07700 
107900 
108100 
1 08300 
108500 
108700 
108900 
1 091 00 
109300 
109500 
1 09700 
109900 
1 1 01 00 
1 1 0300 
110500 
100700 
110900 


REMOVE-DI , 

ERROR-ROUTINE 1 PARAMETERS, 

EERO E-TEKLEENATE , 

VALUE-OF-DI, 

PLACE- OF-DI, 

MATCH-DI, 

SAVE- VALUE, 

SAVE-POSITION? 

INCREASE-LEVEL, 

RESET-POSITION, 

ENTER-DI , 

ENTER-DI - GENERATED , 

ENTER-FILE-NAME, 

DECREASE-LEVEL . 

GRAPH SECTION. 

SET-AUTOREAD-LINE(l ). 

BIG-QUARY: "REPORT" GO TO DATA-DESCRIPTEON 

ELSE ERROR-ROUTINE(l ) 

ERROR-TERMINATE , 

END-OF-QUERY: DATA-NEED. 

% EASY TO USE SAVE-DI INSTEAD OF ENTITY STACK. 

PL ACE- AMD- VA LUE : CLEAR-ENTITIES . 

REPEAT-LINE: INTERRO GATE- STAC IC . 

"OVER" OR *END* SET-AUTOREAD-LINE ( 0 ), GO TO END-OF-QUERY. 
"VALUE" ELSE GO TO POSITION. 

^TOG GLE * ELSE ERROR-ROUTINE (5 ) j GO TO REPEAT-LINE. 
^LITERAL* OR *INTEGER* SAVE-VALUE , RETURN-ENTITY, 
VAIDE-OF-DI , SAVE-ENTITY, 

GET-ENTITY ; GO TO REPEAT-LINE 
ELSE ERE0R-R0UTINE(3); GO TO REPEAT-LINE. 

POSITION: 

"FROM" ELSE GO TO LINE. 

*TOGGLE* ELSE ERROR-ROUTINE (6 ) ; GO TO REPEAT-LINE. 
^INTEGER* SAVE-POSITION, RETURN-ENTITY, 

PLACE-OF-DI , SAVE-ENTITY 

GET-ENTITY, GO TO REPEAT-LINE, 

ELSE ERROR-ROUTINE(4 ) ; GO TO REPEAT-LINE. 

LINE: 

*T OGGLE* RETURN-ENTI TY, 

ERROR-ROUTINE (7 ) . 

*\70RD* MATCH-DI, 

ELSE GO TO LINE-END. 

-*3171 1 * SAVE-ENTITY, 

GO TO REPEAT-LINE, 

ELSE SUPPRESS-ENTITY. 

LINE-END: *ANY-YDRD* ERROR-ROUT INE (8 ). , 



111100 


GO TO REPEAT-LINE. 

111300 

DATA-DE SCRIPTI ON : 

INCREASE-LEVEL 

111500 


GO TO ANY-TXPE. 

111700 

ANY-TXPE: "BEGIN" 

SUPPRES S-ENTITY, GO TO NEXT-LEVEL 

111900 

"END" 

GO TO END-EATA-LESC . 

1 1 21 00 

"OVER" OR *EKD* 

GO TO END-DATA-DE SC 

1 1 2300 

FORMAT " 

GO TO PLACE-ANL-VALUE 

112500 

ELSE GO TO HEXT-FODE . 

1 1 2700 

REPORT-JVEDIUM-ACTI OU : 


1 1 2900 

"NEWSLINE " 

RESET-POSITION, 

113100 


GO TO ANY-TYa . 

113300 

TO7-PAGE " 

RESET-POSE TI ON, 

113500 


GO TO ANY-TXPE. 

113700 

SET-EUNCTI ON-DI : 


113900 

"COUNT" 


114100 


ELSE GO TO SET-SELECTION-ACTION. 

1 14300 

*WOKD* 

ENTER-DI, 

114500 


EL SE EIiROR-EOUTINE( 9 ) , 

114700 


GO TO ANY-TYPE. 

114900 

f !AS ” 

GO TO NEXT-NODE, 

115100 


ELSE ERROR-ROUTINE ( 1 0 ) 

115300 


GO TO ANY-TXPE. 

115500 

*WORD* 

ENTER-DI-GENEAATED, 

115700 


GO TO ANY-TXPE, 

115900 

EL SE ERROR-ROUTINE ( 1 0 ) . 

116100 

GO 

TO ANY-TXPE . 

116300 

SET-SELECTI CN-ACTION : 


116500 

'EOR" 

GO TO NEXT-NODE 

116700 


ELSE GO TO DATA-STRING. 

116900 

SUB- SET-SELECT : ?! EACH" 

GO TO NEXT-NODE , 

117100 


ELSE GO TO GIVEN-VALUE— SELECT. 

1 1 7300 

"OF IT 

ELSE GO TO UNQUE- VALUE-SUBSET. 

117500 

*mw* 

ENTER-EILE-NA11E 

1 1 7700 


GO TO NEXT-LEVEL 

117900 

ELSE ERR0R-R0UTINE(l1 ) 

118100 


GO TO ANY-TXPE. 

118300 

UNIQUE-VALUE-SUBSET : 


118500 

*nord* 

ENTER-DI, GO TO NEXT-LEVEL 

118700 

ELSE ERROR-ROUTI ME ( 1 1 ) 

118900 


GO TO ANY-TXPE. 

119100 

GIVEN- VALUE- SELECT : 


119500 

*WOED* 


1195 00 


ENTER-DI 

1 1 9700 


ELSE ERR0R-R0UTINE( 1 1 ) 

1 1 99CO 


GO TO ANY-TXPE. 

1 20100 

ELSE 

GO TO IGNORE-EOR. 

1 20300 

^LITERAL* GO TO NEXT-LEVEL . 

1 205 00 

IGNORE-EOR: 

REMOVE-DI, 

1 20700 


ERR0R-R0UTINE(l1 ), 

1 20900 


GO TO ANY-TYPE. 

121100 

DATA-STRING: *TOKD* 

ENTER-DI, GO TO ANY-TYPE, 

1 21300 

ELSE GO TO 

' NEXT-NODE. 

1 21500 

V» GO TO ANY-TXPE. 

1 21700 

*ANY-WORD* ERR0R-R0UTINE(1 2) GO TO ANX-TYPE. 



121900 NEXT -LEVEL : "BEGIN" 

1 221 00 ELSE 

1 2 2300 

122500 END-DATA-DESC : 

1 22700 LABEL-1 : 

1 22900 

123100 PROGRAM SECTION. 


GO TO IA BEL-1, 
ERR0l1-B0UT1NE( 1 3 ) , 

GO TO LABEL-1 , 
DECREASE-LEVEL, EXIT(l). 
PERFORM DA TA-DE SCRIP TI ON 
GO TO ANY-TYPE. 


1 23300 IDENTIFICATION DIVISION. 

1 23500 PROGRAM-ID. BIGQRY 
1 23700 ENVIRONMENT DIVISION. 

123900 CONFIGURATION SECTION. 

124100 INPUT-OUTPUT SECTION. 

124300 PILE-CONTROL. 

1 24500 SELECT REPSPC ASSIGN TO READER. 

124700 SELECT DTNEED ASSIGN TO PRINTER. 

124900 DATA DIVISION. 

125100 PILE SECTION. 


1 25300 PD 

REPSPC . 




1 25500 01 

REC-IN 

PIC 

X(80). 


1 25700 PD 

DTNEED. 




1 25900 01 

OUT-REC . 




1 26100 03 

FILLER 

PIC 

X. 


1 26300 03 

AREA1 

PIC 

X(32). 


1 26500 03 

AREA 2 

PIC 

X(33). 


1 26700 03 

AREA3 

PIC X(33). 


126900 04 AREA4 


X(33). 


127100 WORKING-STORAGE SECTION. 


127300 77 

I 

PIC 

99. 


1 27500 '"7 

J 

PIC 

99. 


127700 "7 

K PIC 

99. 



127900 "7 

L PIC 

99. 



128100 "7 

SAVE-VAL 

PIC 

i X(30). 


128300 "7 

SAVE-POS 

PIC 

i 999. 


128500 "7 

DEEPEST-LEVEL 


PIC 99 

VALUE ZERO. 

1 28700 77 

FIRST-DEEPEST 


PIC 99 

VALUE ZERO. 

128900 77 

LAST-DEEPEST 


PIC 99 

VALUE ZERO. 

129100 "7 

KEL-LV 


PIC 99 

VALUE ZERO. 

129300 "7 

1 

\ 

O 


PIC 99 

VALUE ZERO. 

129500 "7 

REL-DI-SN 


PIC 99 

VALUE ZERO. 

129700 r "7 

WORK-1 


PIC X(30). 

129900 77 

TEXT 


PIC X(80). 

130100 77 

TEXT-OUT PIC 

X(132). 


130300 01 

DATA-TABLE. 




130500 

02 D-TABLE 

OCCURS 100 TIMES. 

1 30700 

03 D-SN 



PIC 99. 

130900 

03 D-NAME 



PIC X(30). 

131100 

03 D-LEVEL 


« 

PIC 99. 

131300 

03 D-N-POS 



PIC 999- 

131500 

03 D-N-POS-DI 


PIC 99. 

1 31 700 

03 D-VAL 



PIC X(30) 

131900 

03 D-IYPE 



PIC X. 

132100 01 

CURRENT. 




132300 

02 C-SN 



PIC 99. 

132500 

02 C-NAME 



PIC X(30) 



132700 


02 

C-LEVEL 



PIC 99 . 

132900 


02 

C-NEXT- 

-POS 


PIC 

999. 

133100 


02 

C-NEXT- 

-PO S-AFT-DI-NO PIC 99. 

133300 

01 

ER-MESSAGE. 





133500 

02 

ER- 

-1 . 





133700 

03 


FILLER 

PIC 

X(2>) VALUE 

’NOT A REPORT". 

133900 

03 


FILLER 

PIC 

x( 20) 

VALUE 

'’END DY DEFAULT 

134100 

03 


FILLER 

PIC 

X(20) 

VALUE 

"VALUE-INC QRRECT ", 

134300 

03 


FILLER 

PIC 

X(20) 

VALUE 

’VALUE IGNORED". 

1 34700 

03 


FILLER 

PIC 

X(20) 

VALUE 

"POSITION IGNORED 

134900 

03 


FILLER 

PIC 

X(20) 

VALUE 

"FORMAT IGNORED". 

135100 

03 


FILLER 

PIC 

x( 20) 

VALUE 

"WORD IGNORED". 

135300 

03 


FILLER 

PIC 

X(20) 

VALUE 

"COUNT IGNORED". 

135500 

03 


FILLER 

PIC 

X(20) 

VALUE 

"AS IGNORED". 

135700 

03 


FILLER 

PIC 

X(20) 

VALUE 

'TOR IGNORED". 

135900 

03 


FILLER 

PIC 

X(20) 

VALUE 

'HOT-RECOGNISED ". 

136100 

03 


FILLER 

PIC 

X(20) 

VALUE 

"eegin-asshmed ". 

136300 

03 


THTTiTi'FIT? 

PEC 

x(z) 

VALUE 

ft H. 

136500 

02 : 

ER-2 

REDEFINES 

ER-1 . 



1 36700 

03 

ER-3 

OCCURS 14 

TIMES PIC 

x(20). 


136900 PROCEDURE DIVISION. 

137100 USER SECTION. 

137300 OPffl-FILES. 

137500 OPEN INPUT REPSPC OUTPUT DTNEED. 

137700 MOVE 'REPORT-ANALYSIS " TO TEXT-OUT. 

137900 PERFORM WRITE-LINE THRU USER-EXIT. 

13&1 00 GO TO USER-EXIT. 

138300 READ-LINE. IE TEXT NOT = "OVER” THEN 

138900 READ REPSPC INTO TEXT AT END MOVE "OVER” TO TEXT. 

GO TO USER-EXIT. 

138900 WRITE-LINE. 

139100* 

139300 ’TRITE OUT-REC PROM TEXT-OUT ALTER 2. MOVE SPIEES TO TEXT-OUT. 

139500 MOVE SPACES TO OUT-REC. 

139^00 DOM-1. 

139900 GO TO USER-EXIT. 

1 401 00 ERROR-ROUTINE . 

140300 MOVE PARAMETER-1 TO I. 

1405 CO MOVE ER-3 (i ) TO AREA1 . 

140700 MOVE ENTITY TO AREA 2. 

140900 PERPORM RRITE-LINE-1 . 

141100 GO TO USER-EXIT. 

1 41 300 ERROR-TERMINATE . 

141500 GO TO CLOSE-PARA. 

141700 MATCH-DI. 

141900 MOVE 1 TO I. MOVE ZERO TO SU11 J. 

142100 MAICH-DI-1 . 

14 2300 IE D-NAME(l) = ENTITY MOVE 1 TO SU11 MOVE I TO J 

142500 GO TO MATCH-DI -EXIT. 

14 2700 IE I ~ C-SN GO TO ILATCH-DI-EXIT. 

142900 ADD 1 to I. GO TO MATCII-DI-I. 

143100 MATCH-DI-EXIT. 

143300 EXIT. 



143500 MATCH-DI-EXIT-1 . 

143700 GO TO USER-EXIT. 

143900 VRITE-LIEE-1 . 

1 431 C J WRITE OUT-REC AFTER 2. 

144300 MOVE SPACES TO OUT-REC. 

144500 ENTER-DI . 

144700 ADD 1 TO C-SN. 

144900 MOVE ENTITY TO D-ITAME(C-SN), C-NAME. 

145100 MOVE C-SN TO D-SN(C-Sll). 

145300 MOVE C-LEVEL TO D-LEVEL(C-SIT) . 

145500 MOVE C-ilEXT-POS TO D-N-POS(C-SN). 

145700 MOVE C -NEXT-PO S-AFT-DI -NO TO D-N-POS-DI (C-SN ) . 

145900 MOVE C-SN TO C-NEXT-POS-AFT-DI-NO. 

146100 MOVE "Y" TO D-TXPE(C-SN) . 

146300 ENTER-DI -EXIT. 

146500 GO TO USER-EXIT. 

14C700 SAVE-VALUE. 

146900 MOVE ENTITY- VALUE TO SAVE-VAL. 

1 4 7 1 00 GO TO USER-EXIT. 

147300 SAVE-POSITION. 

147500 MOVE INTEGER TO SAVE-POS. 

147700 GO TO USER-EXIT. 

147900 RESET-POSE TI ON. 

146100 MOVE 1 TO C-NEXT-POS. 

14&300 MOVE ZERO TO C-NEXT-POS-APT-DI-NO . 

148300 GO TO USER-EXIT. 

148-00 MTER-DI-GENERATED. 

148 SCO PERFORM ENTER-DI. 

1.19100 MOVE "GO 11 TO D-TYPE(C-SN). 

149300 GO TO USER-EXIT. 

1 495 00 ENTER-FILE-NAME . 

143700 ADD 1 TO C-SN. 

149900 MOVE ENTITY TO D-NAME(C-SIT). 

150 J 00 MOVE ,r F" TO D-TYPE(C-SN) . 

150300 MOVE C-LEVEL TO D-LEVEL(C-SN) . 

150500 GO TO USER-EXIT. 

1507CO VALUE-0 E-DI . 

15090C PERFORM MATCH-DI THRU MATCH-DI-EXIT. 

15119C MOVE SAVE-VAL TO D-VAL(j). MOVE "C " TO D-TYPE(j). 
151300 GO TO USER-EXIT. 

151500 PLACE-OF-DI. 

151700 PERFORM MATCH-DI THRU MATCH-DI-EXIT . 

151900 MOVE SAVE-POS TO D-N-POS(j). 

152100 MOVE ZERO TO D-N-POS-DI ( J ) . 

152300 REMOVE-DI . 

152^00 SUBTRACT 1 FROM C-SN- 

152900 move d-name(c-sn) TO C-NAME. 

153100 MOVE C-SN TO C-NEXT-PO S- AFT-DI-NO . 

153500 GO TO USER-EXIT. 

153700 INCREASE-LEVEL. 

153900 ADD 1 TO C-LEVEL. 

154100 GO TO USER-EXIT. 



154300 DECREASE-LEVEL. 

154500 SUBTRACT 1 PR CM C-LEVEL. 

154700 GO TO USER-EXIT . 

154900 DATA-NEED. 

155100 MOVE "DATA-NEEDS : » TO AREA1 

155300 PURE CRM YJRITE-LINE-1 . 

155500 PARA-1 . 

155 7TO PERFORM DEEPEST THRU DEEPEST-EHD. 

155900 IP DEEPEST-I EVEL = 1 GO TO P ALLA- 2 ELSE GO TO PARA-1. 

156100 DEEPEST. 

156300 MOVE 1 TO I. 

156500 MOVE ZERO TO DEEPEST-LEVEL. 

156700 CHECK-DEEPEST. 

156900 IP SW05 =3 

157100 MOVE D-TAELE(l) TO OUT-REC PERFORM Y/RITE-LINE-1 . 

157300 IP D-TYPE(l) = "G" OR ”C " MOVE ZERO TO D-LEVEL (i). 

157500 IP D-LEVEL(l) > DEEPEST-LEVEL THEE 

157700 MOVE D-LEVEL (i) TO DEEPEST-LEVEL 

157900 MOVE I TO FIRST-DEEPEST. 

158100 IP D-LEVEL(l) = DEEPEST-LEVEL THEN 

158300 MOVE I TO LAST-DEEPEST. 

158500 CHECK-1. 

158700 ADD 1 to I. 

158900 IP I HOT > C-SH GO TO CHECK-DEEPEST. 

159100 REffiAT-DEEPEST. 

159300 PERFORM OHCE-DEEPEST THRU OHCE-DEEPEST-EHD . 

159500 IP DEEPEST-LEVEL = 1 GO TO DEEPEST-EHD. 

159700 AGAIN. 

159900 SUBTRACT 1 PROM LAST-DEEPEST. 

160100 IP D-LEVEL (LAST-DEEPEST) = DEEPEST-LEVEL GO TO AGAIN. 
160300 MORE-DEEPEST. 

1605 CO SUBTRACT 1 PROM LAST-DEEPEST. 

160700 IP LAST-DEEPEST FIRST-DEEPEST GO TO DEEPEST-EHD. 

160900 IP D-LEVEL (LAST-DEEPEST) = DEEPEST-LEVEL THEN 

161100 GO TO REPEAT-DEEPES T . 

161300 GO TO MORE-DEEPEST. 

161500 DEEPEST-END. 

161700 EXIT. 

101900 OHCE-DEEPEST. 

162100 MOVE DEEPEST-LEVEL TO REL-LV. 

162300 MOVE LAST-DEEPEST 10 I. 

162500 MOVE "RELATION" TO AREA1 . 

162700 ADD 1 TO REL-NO. MOVE EEL-NO TO AREA 2. 

162900 PERFORM Y, RITE-LINE-1 . HOVE ZERO TO REL-DI-SN. 

163100 IP DEEPEST-LEVEL = 1 ADD 1 TO I 

163300 GO TO PARA-1 2. 

163500* FOR LEVEL 1 A ALL DOMAINS ARE KEf DOMAINS. 

163700 MOVE "ATTRIBUTE-DOMAINS” TO AREA1 . PERFORM V) RITE-LINE-1 . 

163900 PARA-1 0 . 

164100 ADD 1 TO REL-DI-SN. 

164300 MOVE REL-DI-SN TO AREA1 . MOVE D-NAME(l) TO AREA 2. 

164500 IP D-TYPE(l) = "F" MOVE "IDENTIPICATI ON-NO " TO AREA3 . 
164700 IP D-IEVEL(l) =~DEEPE ST-LEVEL MOVE ZERO TO D-LEVEL (I ). 
164900 PERFORM URITE-LINE-1 . 



165100 PARA— 1 1 . 

1653C0 SUBTRACT 1 IEOH I. 

■)6535d II D-LEVEL (l ) = RPL-LV GO TO PARA-10. 

165400 II I -Q*u 

165500 II D-LEVEL(l) = .0 j GO TO PARA-U. 

165700 SUBTRACT 1 FRCM EEL-LV,, 

165900 PARA-1 2 . II EEL-LV = ZERO GO TO PARA-14. 

166100 MOVE 'KEY-DOMAINS " TO AREA1 . IERIOIM URITE-LIBE-1 . 
166300 PARA-13. 

166500 II EEL-LV = ZERO GO TO REA-14. 

166700 PARA-15. 

166900, IP D-LEVED(l) = REL-LV GO TO PAM-16. 

167100 SUBTRACT 1 PR CM I. 

167300 II D-LEVEL (i) REL-IV MOVE "ERROR" TO AREA1 PERFORM 
167500 7ZRITE-LIHE-1 GO TO CLOSE-PARA. GO TO PARA-1 5 . 

167700 PARA-1 6 . 

167900 PERFORM PARA-10 THRU 32BEA-11. 

168100 GO TO ERRA-1 3 • 

168300 PARA-14. 

168500 EXIT, 

168700 OHCE-DEEPESI-END. 

168900 EXIT. ’ 

169100 P ARA-2. 

169300 EXIT. 

169500* 

169700 * 

169900 CLOSE-PARA. 

170100 MOVE "END-OF-JOB" TO AREA1 . 

1 70300 PERFORM WRITE-LIHE-1 . 

170500 CLOSE REPSPC DIHEED . 

170700 STOP RUH. 

170900 EKD-OF-JOB. 



